Re: svr4, again
> On Dec 19, 2018, at 5:06 PM, matthew green wrote: > > i would argue that until we're willing to drop a.out exec > entirely we should keep the above. let's not chip and hack > around it. Fair point. Insert "should we get rid of a.out exec, too?" here :-) -- thorpej
re: svr4, again
Jason Thorpe writes: > ...and while we're talking about "questionable utility"... > > COMPAT_AOUT_M68K, COMPAT_M68K4K, and COMPAT_VAX1K are merely exec glue > (well, mostly; COMPAT_AOUT_M68K has some ancient stat()-related > emulation) for what are, at this point, ridiculously old a.out binaries > that you also need to have the entire a.out runtime for. > > I would say at this point that nobody has any business running these > ancient a.out binaries. All of these platforms switched to ELF **long** > ago. Even though these layers are extremely thin, a reasonable argument > could be made that these should go, too. i would argue that until we're willing to drop a.out exec entirely we should keep the above. let's not chip and hack around it. .mrg.
Re: svr4, again
Jason Thorpe wrote: > none of the Mach traps or Mach IPC were ever emulated. I implemented it for now defunct and removed COMPAT_MACH. It was never connected to COMPAT_OSF1, but for COMPAR_DARWIN, It was good enough to run MacOS X command line utilities. Gravestone is there: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/compat/mach/?hideattic=0#dirlist -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: svr4, again
> On Dec 19, 2018, at 3:38 PM, Jason Thorpe wrote: > > Ultrix compatibility is handled with COMPAT_ULTRIX, which is more or less > vanilla 4.3BSD, with a few extra random things. It, like COMPAT_SUNOS, is a > pretty thin layer, but also of questionable utility these days. ...and while we're talking about "questionable utility"... COMPAT_AOUT_M68K, COMPAT_M68K4K, and COMPAT_VAX1K are merely exec glue (well, mostly; COMPAT_AOUT_M68K has some ancient stat()-related emulation) for what are, at this point, ridiculously old a.out binaries that you also need to have the entire a.out runtime for. I would say at this point that nobody has any business running these ancient a.out binaries. All of these platforms switched to ELF **long** ago. Even though these layers are extremely thin, a reasonable argument could be made that these should go, too. -- thorpej
Re: svr4, again
> On Dec 19, 2018, at 1:48 PM, Johnny Billquist wrote: > > Unless I remember wrong, it's needed for Ultrix compatibility on VAX (and > maybe MIPS?). Ultrix compatibility is handled with COMPAT_ULTRIX, which is more or less vanilla 4.3BSD, with a few extra random things. It, like COMPAT_SUNOS, is a pretty thin layer, but also of questionable utility these days. Same goes for COMPAT_OSF1 (for Digital Unix on Alpha) ... a thicker layer than COMPAT_ULTRIX, but not nearly as thick as COMPAT_SVR4 or COMPAT_IBCS2. COMPAT_OSF1 was never really fully implemented ... a bunch of stuff worked, but none of the Mach traps or Mach IPC were ever emulated. Outreach on those specific port mailing lists (port-pmax, port-vax, port-alpha, port-sparc*) to determine "how useful is this these days?" is probably warranted. -- thorpej
Re: svr4, again
On Wed, Dec 19, 2018 at 11:01:27AM -0700, Warner Losh wrote: > FreeBSD ditched SYSV maybe 2 years ago, but > we still have IBCS in the tree because people are still using it (last we > checked) and bug fixes / reports are still trickling in... > > Which is a long way of saying 'be careful' :) > > Warner That statement lasted all of a few hours. https://v4.freshbsd.org/commit/freebsd/src/342242
Re: svr4, again
Unless I remember wrong, it's needed for Ultrix compatibility on VAX (and maybe MIPS?). Johnny On 2018-12-19 19:46, Brian Buhrow wrote: hello. The COMPAT_IBCS2 is for SCO OpenServer and Unixware binary compatibility. I used it regularly to run Oracle database clients and servers on NetBSD which were compiled for OpenServer. OpenServer hasn't changed much in the years since I did that, but is anyone really using OpenServer anymore? And, more aptly, is any company still building software for OpenServer? It may be the case that someone is still using some old software for OpenServer, but it's probably a legacy system that can be run as a VM going forward to protect it from hardware changes which OpenServer is never going to support. In short, COMPAT_IBCS2 worked well, but it too, should probably go, again with the proviso that instructions be left around on how one might use it if one really needs it. -thanks -Brian On Dec 19, 5:32pm, Maxime Villard wrote: } Subject: Re: svr4, again } Le 19/12/2018 à 13:46, Maxime Villard a écrit : } While I'm at it, there was a conversation about compat_ibcs2 [1]. See } the thread, basically it is a compat for SVR3 on Vax. It seems that no } one knew exactly what was the purpose of it. } } Maybe something we could retire as well (even though it likely isn't } as broken as compat_svr4). Don't know, throwing this here in case } someone cares. } -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: svr4, again
On Tue, Dec 18, 2018 at 09:39:18AM +0100, Maxime Villard wrote: > I've made one: > > http://wiki.netbsd.org/attic_museum/ > > I took the entries from src/doc/CHANGES. Thanks! -- David A. Holland dholl...@netbsd.org
Re: svr4, again
Le 19/12/2018 à 13:46, Maxime Villard a écrit : Le 18/12/2018 à 21:38, Christos Zoulas a écrit : In article , JaromÃr DoleÄ ek wrote: Le mar. 18 déc. 2018 à 13:16, Maxime Villard a écrit : It is clear that COMPAT_SVR4 is completely buggy, but to be clear on the use of the code: +1 to removal for COMPAT_SVR4, there is always attic. I remember I've been also doing some mechanical changes in the area in past, and also encountered things which were broken just by casual browsing. Which I did not fix because I did not have "srv4" binary I would need to run. It's simply not useful any more. Just remove it already :-) If we want it back we can resurrect it. christos so, I will remove Done. While I'm at it, there was a conversation about compat_ibcs2 [1]. See the thread, basically it is a compat for SVR3 on Vax. It seems that no one knew exactly what was the purpose of it. Maybe something we could retire as well (even though it likely isn't as broken as compat_svr4). Don't know, throwing this here in case someone cares. [1] http://mail-index.netbsd.org/port-vax/2017/08/02/msg003024.html
