Re: svr4, again
I'd rather not - on the rare occasions when I boot up my pmax, I do actually have a couple of Ultrix binaries I run. If I couldn't, about 5 years of my academic work would be lost to me (because Digital's packaged applications couldn't export to any portable format except print-analogues like Postscript). What needs to be done to Ultrix compatibility to keep it alive? I will admit to not looking at it in at least a decade, but it was pretty darned small, wasn't it? On Sat, Mar 09, 2019 at 10:56:34AM -0500, Christos Zoulas wrote: > Let's retire them. > > christos > > > On Mar 9, 2019, at 5:28 AM, Maxime Villard wrote: > > > > Re-reading this thread - which was initially about SVR4 but which diverged > > in > > all directions -, I see there were talks about retiring COMPAT_ULTRIX and > > COMPAT_OSF1, because these were of questionable utility, in addition to > > being > > clear dead wood (in terms of use case, commits in these areas, and ability > > to > > test changes). > > > > Does anyone have anything to say? -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but because it is right." --Andrei Sakharov
Re: svr4, again
On Mar 9, 6:38am, "Jonathan A. Kollasch" wrote: } On Sat, Mar 09, 2019 at 11:28:05AM +0100, Maxime Villard wrote: } > Re-reading this thread - which was initially about SVR4 but which diverged in } > all directions -, I see there were talks about retiring COMPAT_ULTRIX and } > COMPAT_OSF1, because these were of questionable utility, in addition to being } > clear dead wood (in terms of use case, commits in these areas, and ability to } > test changes). } > } > Does anyone have anything to say? } } Possibly, although I doubt they'll notice they want to say something in } this thread with the current Subject line... I'd suggest starting a } new thread, possibly CCing port-pmax@ and port-alpha@ as relevant. Ah, don't forget about port-vax... I even have a uVAX 1000 running Ultrix. Although it's been quite some time since I've powered it up and I think it was having problems with the hard drive. }-- End of excerpt from "Jonathan A. Kollasch"
Re: svr4, again
Let's retire them. christos > On Mar 9, 2019, at 5:28 AM, Maxime Villard wrote: > > Re-reading this thread - which was initially about SVR4 but which diverged in > all directions -, I see there were talks about retiring COMPAT_ULTRIX and > COMPAT_OSF1, because these were of questionable utility, in addition to being > clear dead wood (in terms of use case, commits in these areas, and ability to > test changes). > > Does anyone have anything to say?
Re: svr4, again
Agreed. I think they (especially osf1) should go, but new thread warranted. -- thorpej Sent from my iPhone. > On Mar 9, 2019, at 4:38 AM, Jonathan A. Kollasch > wrote: > >> On Sat, Mar 09, 2019 at 11:28:05AM +0100, Maxime Villard wrote: >> Re-reading this thread - which was initially about SVR4 but which diverged in >> all directions -, I see there were talks about retiring COMPAT_ULTRIX and >> COMPAT_OSF1, because these were of questionable utility, in addition to being >> clear dead wood (in terms of use case, commits in these areas, and ability to >> test changes). >> >> Does anyone have anything to say? > > Possibly, although I doubt they'll notice they want to say something in > this thread with the current Subject line... I'd suggest starting a > new thread, possibly CCing port-pmax@ and port-alpha@ as relevant. > >Jonathan Kollasch
Re: svr4, again
On Sat, Mar 09, 2019 at 11:28:05AM +0100, Maxime Villard wrote: > Re-reading this thread - which was initially about SVR4 but which diverged in > all directions -, I see there were talks about retiring COMPAT_ULTRIX and > COMPAT_OSF1, because these were of questionable utility, in addition to being > clear dead wood (in terms of use case, commits in these areas, and ability to > test changes). > > Does anyone have anything to say? Possibly, although I doubt they'll notice they want to say something in this thread with the current Subject line... I'd suggest starting a new thread, possibly CCing port-pmax@ and port-alpha@ as relevant. Jonathan Kollasch
Re: svr4, again
Re-reading this thread - which was initially about SVR4 but which diverged in all directions -, I see there were talks about retiring COMPAT_ULTRIX and COMPAT_OSF1, because these were of questionable utility, in addition to being clear dead wood (in terms of use case, commits in these areas, and ability to test changes). Does anyone have anything to say?
Re: svr4, again
Le 21/12/2018 à 12:19, Maxime Villard a écrit : Le 21/12/2018 à 10:25, Anders Magnusson a écrit : Den 2018-12-20 kl. 21:29, skrev Maxime Villard: Le 20/12/2018 à 18:11, Kamil Rytarowski a écrit : https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386 On the other hand unless we need it for bootloaders, drivers or something needed to run NetBSD, I'm for removal of srv3, sunos etc compat. Yes. So, first things first, and to come back to my email about ibcs2: what are the reasons for keeping it? As I said previously, this is not for x86 but for Vax. As was also said, FreeBSD removed it just a few days ago. I'm bringing up compat_ibcs2 because I did start a thread on port-vax@ about it last year (as quoted earlier), and back then it seemed that no one knew what was the use case on Vax. It was something that Matt Thomas used for a customer running some commercial program, but it was a long time ago (15 years?). I've never heard of any other use, so from my perspective IBCS2 not relevant (anymore). -- ragge Alright, so I propose that we retire it. After a quick scroll-reread of the thread it seems to me we all agree on that. Anyone objecting etc? So, no one? I will remove it soon...
Re: svr4, again
On Sun, Dec 23, 2018 at 04:36:46PM +0100, Maxime Villard wrote: > Having said that, you would be getting much better results if you were just > emulating SunOS (or something else) directly rather than going through the > expense of finding out which NetBSD version had the most functional > compat_sunos to then launch a SunOS program on it, all in a VM... You are ignoring licensing implications and involved pain of test setup. It was very cool when you could just mount the target devices disk on a random -current setup and then chroot there... Martin
Re: svr4, again
Le 22/12/2018 à 22:14, Brandon Wickelhaus a écrit : Hello, [...] What I'd ask or suggest is, along with the docs being shoved in the attic, perhaps an idea of what legacy or EOL'd version one many expect these things to have been functional, so in this wonderful world of Emulation, people could spin up a VM of a previous OS and try in a properly sandboxed manner? I can add a column in the attic museum page to say what is the last version of NetBSD that supports the feature. But this doesn't give a clear indication that it is the version where it was the most functional. Having said that, you would be getting much better results if you were just emulating SunOS (or something else) directly rather than going through the expense of finding out which NetBSD version had the most functional compat_sunos to then launch a SunOS program on it, all in a VM...
Re: svr4, again
Hello, I've a use case that could matter for some others, but as the units aren't networked I can get by with using EOL'd version of the OS to meet the client's needs. Several 'on hour photo' style shops were given/sold Kodak and other equipment with a sun4m based architecture. The boards -aren't- Sparcstation IPX, LX, or Classics, but the boards will work in a pinch as replacements... they fit against the exposed card-edge slot. Anyway... a client had a drive failure on one unit, and asked me to see if I could get another OS running with the same functionality. NetBSD as of say four years ago ran, but I am not sure if it was -just- SUN compat, or if the SRV4 was added and required as well... (We utilized a few of the binaries salvaged to do some processing to what we recovered what was on the old drives) as well as a binary to use the slide scanner and ... some other function that I am not recalling. There was also another case of some astronomy lab data that a few grad students at the Uni in town needed converted from an old SunOS data set to something readable by a modern program. I know that was -only- SUN compat, but it worked like a charm. What I'd ask or suggest is, along with the docs being shoved in the attic, perhaps an idea of what legacy or EOL'd version one many expect these things to have been functional, so in this wonderful world of Emulation, people could spin up a VM of a previous OS and try in a properly sandboxed manner? -Brandon
Re: svr4, again
Le 21/12/2018 à 10:25, Anders Magnusson a écrit : Den 2018-12-20 kl. 21:29, skrev Maxime Villard: Le 20/12/2018 à 18:11, Kamil Rytarowski a écrit : https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386 On the other hand unless we need it for bootloaders, drivers or something needed to run NetBSD, I'm for removal of srv3, sunos etc compat. Yes. So, first things first, and to come back to my email about ibcs2: what are the reasons for keeping it? As I said previously, this is not for x86 but for Vax. As was also said, FreeBSD removed it just a few days ago. I'm bringing up compat_ibcs2 because I did start a thread on port-vax@ about it last year (as quoted earlier), and back then it seemed that no one knew what was the use case on Vax. It was something that Matt Thomas used for a customer running some commercial program, but it was a long time ago (15 years?). I've never heard of any other use, so from my perspective IBCS2 not relevant (anymore). -- ragge Alright, so I propose that we retire it. After a quick scroll-reread of the thread it seems to me we all agree on that. Anyone objecting etc?
Re: svr4, again
Den 2018-12-20 kl. 21:29, skrev Maxime Villard: Le 20/12/2018 à 18:11, Kamil Rytarowski a écrit : https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386 On the other hand unless we need it for bootloaders, drivers or something needed to run NetBSD, I'm for removal of srv3, sunos etc compat. Yes. So, first things first, and to come back to my email about ibcs2: what are the reasons for keeping it? As I said previously, this is not for x86 but for Vax. As was also said, FreeBSD removed it just a few days ago. I'm bringing up compat_ibcs2 because I did start a thread on port-vax@ about it last year (as quoted earlier), and back then it seemed that no one knew what was the use case on Vax. It was something that Matt Thomas used for a customer running some commercial program, but it was a long time ago (15 years?). I've never heard of any other use, so from my perspective IBCS2 not relevant (anymore). -- ragge
Re: svr4, again
On Thu, Dec 20, 2018, 6:17 PM Maxime Villard Le 20/12/2018 à 18:11, Kamil Rytarowski a écrit : > > https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386 > > > > On the other hand unless we need it for bootloaders, drivers or > > something needed to run NetBSD, I'm for removal of srv3, sunos etc > compat. > > Yes. > > So, first things first, and to come back to my email about ibcs2: what are > the reasons for keeping it? As I said previously, this is not for x86 but > for Vax. As was also said, FreeBSD removed it just a few days ago. > It had been disconnected from the build for a while too... Warner I'm bringing up compat_ibcs2 because I did start a thread on port-vax@ about > it last year (as quoted earlier), and back then it seemed that no one knew > what was the use case on Vax. >
Re: svr4, again
Le 20/12/2018 à 18:11, Kamil Rytarowski a écrit : https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386 On the other hand unless we need it for bootloaders, drivers or something needed to run NetBSD, I'm for removal of srv3, sunos etc compat. Yes. So, first things first, and to come back to my email about ibcs2: what are the reasons for keeping it? As I said previously, this is not for x86 but for Vax. As was also said, FreeBSD removed it just a few days ago. I'm bringing up compat_ibcs2 because I did start a thread on port-vax@ about it last year (as quoted earlier), and back then it seemed that no one knew what was the use case on Vax.
Re: svr4, again
matthew green wrote: > Christos Zoulas writes: > > > > Well, I still have a lisp from 0.9 :-) Anyway if we get rid of a.out we > > might as well get rid of compat <= 1.5... > > netbsd had ELF ports before 1.5. i forget when, but at > least alpha and maybe mips were ELF before i386/sparc's > conversion from a.out in 1.5. > > IIRC. For MIPS I've got some old binaries lying about. There's a '95 a.out binary and a '97 ELF binary so looks like MIPS switched at 1.1 or 1.2. Probably easier to look at share/mk CVS history to work out when :) Cheers, Simon.
Re: svr4, again
> On Dec 20, 2018, at 2:36 PM, matthew green wrote: > > netbsd had ELF ports before 1.5. i forget when, but at > least alpha and maybe mips were ELF before i386/sparc's > conversion from a.out in 1.5. Yah, I think Alpha was ECOFF **very briefly**, but went ELF pretty quick. -- thorpej
re: svr4, again
Christos Zoulas writes: > In article <3af3b7c6-d34e-471d-8cf8-a411e9032...@me.com>, > Jason Thorpe wrote: > >While I agree that it’s not exactly difficult to maintain the a.out > >exec package, I do wonder if there is anyone out there actually running > >ancient a.out binaries. > > Well, I still have a lisp from 0.9 :-) Anyway if we get rid of a.out we > might as well get rid of compat <= 1.5... netbsd had ELF ports before 1.5. i forget when, but at least alpha and maybe mips were ELF before i386/sparc's conversion from a.out in 1.5. IIRC. .mrg.
Re: svr4, again
> On Dec 20, 2018, at 9:34 AM, Terry Moore wrote: > > Nothing as nice as Franz Lisp. Internal little utilities for which we don’t > have source handy and/or we're too lazy to rebuild. I have a (licensed) > version of Unipress Emacs, but I finally gave up and rebuilt that around the > 5.0 transition because of X issues; and as I'm the only user here for that, > and I've finally moved on, it's only the old utilities. It's always just been > cheaper (in time) to dig up the 0.9 emulation. We've been running NetBSD > since 1994 or so, I think, so these kinds of things accumulate. If github had > been around in 1994 they'd probably all be open source and readily buildable. > But... > > The big issue with maintaining older tools is that they don't always > recompile with new compilers; even if they actually work. People make the > toolchains more and more persnickety, and it's just not worth the effort to > track the compiler flavor of the week, when the problem is not that the tools > are wrong, but that they were written with a more "assembly-language in C" > mindset. Which is seriously out of style. Ok, you win :-) -- thorpej
Re: svr4, again
> On Dec 20, 2018, at 12:29 PM, Maxime Villard wrote: > So, first things first, and to come back to my email about ibcs2: what are > the reasons for keeping it? As I said previously, this is not for x86 but > for Vax. As was also said, FreeBSD removed it just a few days ago. > > I'm bringing up compat_ibcs2 because I did start a thread on port-vax@ about > it last year (as quoted earlier), and back then it seemed that no one knew > what was the use case on Vax. It seems reasonable to remove COMPAT_IBCS2, for the same reasons as COMPAT_SVR4. -- thorpej
RE: svr4, again
> Jason Thorpe wrote: While I agree that it’s not exactly difficult to maintain the a.out exec package, I do wonder if there is anyone out there actually running ancient a.out binaries. >>> >>> NetBSD 0.9 i386 a.out yes. >> >> Here, too. > > Well, then you have my sympathies, my admiration, and my curiosity all at the > same time! > > No, seriously, what ancient binaries are you running? (Ok, I admit, it's > pretty cool that it still works after all this time...) Nothing as nice as Franz Lisp. Internal little utilities for which we don’t have source handy and/or we're too lazy to rebuild. I have a (licensed) version of Unipress Emacs, but I finally gave up and rebuilt that around the 5.0 transition because of X issues; and as I'm the only user here for that, and I've finally moved on, it's only the old utilities. It's always just been cheaper (in time) to dig up the 0.9 emulation. We've been running NetBSD since 1994 or so, I think, so these kinds of things accumulate. If github had been around in 1994 they'd probably all be open source and readily buildable. But... The big issue with maintaining older tools is that they don't always recompile with new compilers; even if they actually work. People make the toolchains more and more persnickety, and it's just not worth the effort to track the compiler flavor of the week, when the problem is not that the tools are wrong, but that they were written with a more "assembly-language in C" mindset. Which is seriously out of style. --Terry
Re: svr4, again
On 20.12.2018 20:29, Robert Swindells wrote: > > Kamil Rytarowski wrote: >> On 20.12.2018 17:58, Jason Thorpe wrote: >>> >>> On Dec 20, 2018, at 8:52 AM, Terry Moore wrote: Kamil Rytarowski wrote: >> While I agree that it’s not exactly difficult to maintain the a.out exec >> package, I do wonder if there is anyone out there actually running >> ancient a.out binaries. >> > > NetBSD 0.9 i386 a.out yes. Here, too. >>> >>> Well, then you have my sympathies, my admiration, and my curiosity all at >>> the same time! >>> >>> No, seriously, what ancient binaries are you running? (Ok, I admit, it's >>> pretty cool that it still works after all this time...) >>> >>> -- thorpej >>> >> >> https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386 > > Maybe worth pointing out that to use that package you would also need > an a.out gcc toolchain. > > The Lisp compiler generates C that you then compile and link into the > running Lisp executable. > a.out toolchain is needed for liszt, lisp works fine without it. signature.asc Description: OpenPGP digital signature
Re: svr4, again
Kamil Rytarowski wrote: >On 20.12.2018 17:58, Jason Thorpe wrote: >> >> >>> On Dec 20, 2018, at 8:52 AM, Terry Moore wrote: >>> >>> Kamil Rytarowski wrote: > While I agree that it’s not exactly difficult to maintain the a.out exec > package, I do wonder if there is anyone out there actually running > ancient a.out binaries. > NetBSD 0.9 i386 a.out yes. >>> >>> Here, too. >> >> Well, then you have my sympathies, my admiration, and my curiosity all at >> the same time! >> >> No, seriously, what ancient binaries are you running? (Ok, I admit, it's >> pretty cool that it still works after all this time...) >> >> -- thorpej >> > >https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386 Maybe worth pointing out that to use that package you would also need an a.out gcc toolchain. The Lisp compiler generates C that you then compile and link into the running Lisp executable.
Re: svr4, again
In article <3af3b7c6-d34e-471d-8cf8-a411e9032...@me.com>, Jason Thorpe wrote: >While I agree that itâs not exactly difficult to maintain the a.out >exec package, I do wonder if there is anyone out there actually running >ancient a.out binaries. Well, I still have a lisp from 0.9 :-) Anyway if we get rid of a.out we might as well get rid of compat <= 1.5... christos
RE: svr4, again
Kamil Rytarowski wrote: >> While I agree that it’s not exactly difficult to maintain the a.out exec >> package, I do wonder if there is anyone out there actually running ancient >> a.out binaries. >> > > NetBSD 0.9 i386 a.out yes. Here, too.
Re: svr4, again
On 20.12.2018 17:58, Jason Thorpe wrote: > > >> On Dec 20, 2018, at 8:52 AM, Terry Moore wrote: >> >> Kamil Rytarowski wrote: While I agree that it’s not exactly difficult to maintain the a.out exec package, I do wonder if there is anyone out there actually running ancient a.out binaries. >>> >>> NetBSD 0.9 i386 a.out yes. >> >> Here, too. > > Well, then you have my sympathies, my admiration, and my curiosity all at the > same time! > > No, seriously, what ancient binaries are you running? (Ok, I admit, it's > pretty cool that it still works after all this time...) > > -- thorpej > https://github.com/krytarowski/franz-lisp-netbsd-0.9-i386 On the other hand unless we need it for bootloaders, drivers or something needed to run NetBSD, I'm for removal of srv3, sunos etc compat. signature.asc Description: OpenPGP digital signature
Re: svr4, again
> On Dec 20, 2018, at 8:52 AM, Terry Moore wrote: > > Kamil Rytarowski wrote: >>> While I agree that it’s not exactly difficult to maintain the a.out exec >>> package, I do wonder if there is anyone out there actually running ancient >>> a.out binaries. >>> >> >> NetBSD 0.9 i386 a.out yes. > > Here, too. Well, then you have my sympathies, my admiration, and my curiosity all at the same time! No, seriously, what ancient binaries are you running? (Ok, I admit, it's pretty cool that it still works after all this time...) -- thorpej
Re: svr4, again
We're shipping binaries in the source tree to make this hold up. src/libexec/ld.aout_so/*.uue
Re: svr4, again
On 20.12.2018 17:03, Jason Thorpe wrote: > While I agree that it’s not exactly difficult to maintain the a.out exec > package, I do wonder if there is anyone out there actually running ancient > a.out binaries. > NetBSD 0.9 i386 a.out yes. signature.asc Description: OpenPGP digital signature
Re: svr4, again
While I agree that it’s not exactly difficult to maintain the a.out exec package, I do wonder if there is anyone out there actually running ancient a.out binaries. -- thorpej Sent from my iPhone. > On Dec 20, 2018, at 12:17 AM, David Holland wrote: > > On Wed, Dec 19, 2018 at 05:18:15PM -0800, Jason Thorpe 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 :-) > > No... > > -- > David A. Holland > dholl...@netbsd.org
Re: svr4, again
On Wed, Dec 19, 2018 at 05:18:15PM -0800, Jason Thorpe 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 :-) No... -- David A. Holland dholl...@netbsd.org
Re: svr4, again
Le 20/12/2018 à 00:40, Warner Losh a écrit : On Wed, Dec 19, 2018 at 4:38 PM mailto:m...@netbsd.org>> wrote: 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 I had no idea this was going to happen so quickly... Warner In the end, do we need to be this careful? Note that our compat_ibcs2 isn't available on x86; it used to, until one or two years ago, when it was still enabled by default on i386. It was then removed, as part of the Great Cleanup following defcon. Today, compat_ibcs2 is really only for Vax.
Re: svr4, again
On Wed, Dec 19, 2018 at 4:38 PM wrote: > 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 I had no idea this was going to happen so quickly... Warner
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
Re: svr4, again
On Mon, Dec 17, 2018 at 02:57:54PM +0100, Maxime Villard wrote: > Should I re-start a fight about dropping COMPAT_SVR4? Because I keep finding > bugs, and it's becoming tiring. Over time I've come across at least a good > dozen of bugs in it, by just grepping through the tree searching for unrelated > things. The last one is this [1], while working on kcov, exit1() is called but > the proc mutex is not held. > > The thing is just broken beyond repair. > > It is dead wood that consumes APIs and makes stuff harder to change, just like > the network components we (thankfully) retired. > > [1] https://nxr.netbsd.org/xref/src/sys/compat/svr4_32/svr4_32_signal.c#661 +1 for removing compat
Re: svr4, again
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
Re: svr4, again
On Tue, Dec 18, 2018 at 06:20:12PM -, Michael van Elst wrote: > thor...@me.com (Jason Thorpe) writes: > > > AFAIK, none of our m68k platforms ever had a "native" SVR4. > > http://en.wikipedia.org/wiki/Amiga_Unix A donation of which is what made COMPAT_SVR4 on m68k possible. :-) Not that I'd had any particular use for it, let alone anyone else. - Klaus
Re: svr4, again
thor...@me.com (Jason Thorpe) writes: > AFAIK, none of our m68k platforms ever had a "native" SVR4. http://en.wikipedia.org/wiki/Amiga_Unix Also some hardware running NetBSD/mvme68k had a native SVR4. AFAIK mac68k only got up to SVR3. The compat code was also necessary to run some m68k SunOS binaries. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: svr4, again
> On Dec 18, 2018, at 12:39 AM, Maxime Villard wrote: > > I've made one: > > http://wiki.netbsd.org/attic_museum/ > > I took the entries from src/doc/CHANGES. This is great, thanks. -- thorpej
Re: svr4, again
> On Dec 18, 2018, at 4:16 AM, Maxime Villard wrote: > > Judging by the configuration files: > > * COMPAT_SVR4 is available on sparc, sparc64, *68k, sun2, sun3, atari, > hp300, amiga. This is in terms of files.svr4 inclusions. I suspect that > a part of these inclusions were added automatically without real > testing (a bit like PMCs, where people copied the PMC logic in each > port without ever implementing the support for real), and that the only > use cases were sparc, sparc64 and i386. I can speak a little to this... There were commercially available SVR4 variants for m68k systems ... at the time, there was a pretty big push for parity among the m68k systems we supported (there were lots of dumb reasons why the user land binaries were inconsistent from one m68k platform to the next, and there was a concerted effort to address that over a couple of releases), so that likely explains why COMPAT_SVR4 was added to *all* of the m68k kernel configs Although, to be honest, I would be really shocked if it would have actually worked on Sun 2, because the 68010 lacks instructions and addressing modes that SVR4 would have almost certainly required (and is why we don't have shared libraries on our Sun 2 port, IIRC). AFAIK, none of our m68k platforms ever had a "native" SVR4. -- thorpej
Re: svr4, again
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. Jaromir
Re: svr4, again
Le 18/12/2018 à 06:51, Martin Husemann a écrit : On Mon, Dec 17, 2018 at 02:35:11PM -0800, Jason Thorpe wrote: On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote: Now I'm re-putting the subject on the table, because, as if it wasn't already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep unintentionally finding bugs in it, and it just doesn't make any sense to keep it to me. I'm far from authoritative on this, but I agree that it makes sense to remove it (I mean, jeez, if Christos isn't even using it... ;-). Me neither - last I tried on sparc64 it was only usefull for a very limited set of binaries and far from trivial to fix. There were bugs in the mmap emulation and newer Solaris needed additional syscalls for ld.elf_so. I put fixing it somewhere on my todo list (and even have some diagnostic kernel modificiations to make it print out more stuff before binaries fail), but the fixing part had no chance to bubble up into visibility of the front page there for a year or so and unlikely is going to happen anytime soon. Better fish to fry elsewhere... So I won't object removal from the sparc64 PoV. Martin It is clear that COMPAT_SVR4 is completely buggy, but to be clear on the use of the code: Both COMPAT_SVR4 and COMPAT_SVR4_32 are disabled by default; this was done following the DEFCON fiasco. Judging by the configuration files: * COMPAT_SVR4 is available on sparc, sparc64, *68k, sun2, sun3, atari, hp300, amiga. This is in terms of files.svr4 inclusions. I suspect that a part of these inclusions were added automatically without real testing (a bit like PMCs, where people copied the PMC logic in each port without ever implementing the support for real), and that the only use cases were sparc, sparc64 and i386. * COMPAT_SVR4_32 is available only on sparc64. MIPS has a svr4_machdep.c file, but it seems that there is no reference to it. At a first glance it looks like dead code that is not compiled. Each architecture has an MD device-major for svr4_net, even when the arch doesn't support COMPAT_SVR4. This too looks like dead code.
Re: svr4, again
Le 17/12/2018 à 23:35, Jason Thorpe a écrit : On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote: Now I'm re-putting the subject on the table, because, as if it wasn't already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep unintentionally finding bugs in it, and it just doesn't make any sense to keep it to me. I'm far from authoritative on this, but I agree that it makes sense to remove it (I mean, jeez, if Christos isn't even using it... ;-). Again, as with drivers that we retire, I also think it makes sense to document in an obvious location in the source tree where it can be found if someone goes looking for it (like "hey, if you check out this tag, you can get the last version of it before it was removed") sort of thing. That way, if someone wants to put their money where their mouth is and actually fix it, then they can't complain that you made it hard to find. Couvrez-vous le cul, oui? -- thorpej I've made one: http://wiki.netbsd.org/attic_museum/ I took the entries from src/doc/CHANGES.
Re: svr4, again
On Mon, Dec 17, 2018 at 02:35:11PM -0800, Jason Thorpe wrote: > > > > On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote: > > > > Now I'm re-putting the subject on the table, because, as if it wasn't > > already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep > > unintentionally finding bugs in it, and it just doesn't make any sense > > to keep it to me. > > I'm far from authoritative on this, but I agree that it makes sense to remove > it (I mean, jeez, if Christos isn't even using it... ;-). Me neither - last I tried on sparc64 it was only usefull for a very limited set of binaries and far from trivial to fix. There were bugs in the mmap emulation and newer Solaris needed additional syscalls for ld.elf_so. I put fixing it somewhere on my todo list (and even have some diagnostic kernel modificiations to make it print out more stuff before binaries fail), but the fixing part had no chance to bubble up into visibility of the front page there for a year or so and unlikely is going to happen anytime soon. Better fish to fry elsewhere... So I won't object removal from the sparc64 PoV. Martin
Re: svr4, again
> On Dec 17, 2018, at 2:00 PM, Maxime Villard wrote: > > Now I'm re-putting the subject on the table, because, as if it wasn't > already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep > unintentionally finding bugs in it, and it just doesn't make any sense > to keep it to me. I'm far from authoritative on this, but I agree that it makes sense to remove it (I mean, jeez, if Christos isn't even using it... ;-). Again, as with drivers that we retire, I also think it makes sense to document in an obvious location in the source tree where it can be found if someone goes looking for it (like "hey, if you check out this tag, you can get the last version of it before it was removed") sort of thing. That way, if someone wants to put their money where their mouth is and actually fix it, then they can't complain that you made it hard to find. Couvrez-vous le cul, oui? -- thorpej
Re: svr4, again
Le 17/12/2018 à 19:21, Hisashi T Fujinaka a écrit : On Mon, 17 Dec 2018, Christos Zoulas wrote: In article <7fd8e657-dafb-1efc-0a23-762803589...@m00nbsd.net>, Maxime Villard wrote: Should I re-start a fight about dropping COMPAT_SVR4? Because I keep finding bugs, and it's becoming tiring. Over time I've come across at least a good dozen of bugs in it, by just grepping through the tree searching for unrelated things. The last one is this [1], while working on kcov, exit1() is called but the proc mutex is not held. The thing is just broken beyond repair. It is dead wood that consumes APIs and makes stuff harder to change, just like the network components we (thankfully) retired. [1] https://nxr.netbsd.org/xref/src/sys/compat/svr4_32/svr4_32_signal.c#661 I would start by checking if anyone is using it. Can it still run Solaris binaries? I have not used it in a decade or more... Why start a fight? You should first ask if someone is using it, as Christos says. Already done, repeatedly, here [1], and here [2], and long before that in private discussions with several people. And before myself, I seem to remember that one or two people did talk about that, but I can't remember who and when. The conclusion is always the same: no one uses compat_svr4. Another fact is that it is completely buggy; it has cost us in DEFCON 25, and still remains today a maintenance burden. This is the same kind of burden for dead wood in general: APIs that are consumed, changes that can't be tested, bugs that keep being found, and so on. There have been all kinds of wrong and incoherent arguments given to keep it, which have more or less started brawls in the past. Now I'm re-putting the subject on the table, because, as if it wasn't already glaringly obvious, COMPAT_SVR4 is broken beyond repair. I keep unintentionally finding bugs in it, and it just doesn't make any sense to keep it to me. [1] http://mail-index.netbsd.org/port-sparc64/2017/07/31/msg002635.html [2] http://mail-index.netbsd.org/port-sparc64/2017/08/26/msg002651.html
Re: svr4, again
On Mon, 17 Dec 2018, Christos Zoulas wrote: In article <7fd8e657-dafb-1efc-0a23-762803589...@m00nbsd.net>, Maxime Villard wrote: Should I re-start a fight about dropping COMPAT_SVR4? Because I keep finding bugs, and it's becoming tiring. Over time I've come across at least a good dozen of bugs in it, by just grepping through the tree searching for unrelated things. The last one is this [1], while working on kcov, exit1() is called but the proc mutex is not held. The thing is just broken beyond repair. It is dead wood that consumes APIs and makes stuff harder to change, just like the network components we (thankfully) retired. [1] https://nxr.netbsd.org/xref/src/sys/compat/svr4_32/svr4_32_signal.c#661 I would start by checking if anyone is using it. Can it still run Solaris binaries? I have not used it in a decade or more... Why start a fight? You should first ask if someone is using it, as Christos says. -- Hisashi T Fujinaka - ht...@twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
Re: svr4, again
In article <7fd8e657-dafb-1efc-0a23-762803589...@m00nbsd.net>, Maxime Villard wrote: >Should I re-start a fight about dropping COMPAT_SVR4? Because I keep finding >bugs, and it's becoming tiring. Over time I've come across at least a good >dozen of bugs in it, by just grepping through the tree searching for unrelated >things. The last one is this [1], while working on kcov, exit1() is called but >the proc mutex is not held. > >The thing is just broken beyond repair. > >It is dead wood that consumes APIs and makes stuff harder to change, just like >the network components we (thankfully) retired. > >[1] https://nxr.netbsd.org/xref/src/sys/compat/svr4_32/svr4_32_signal.c#661 I would start by checking if anyone is using it. Can it still run Solaris binaries? I have not used it in a decade or more... christos
