Date: Sat, 20 Sep 1997 12:34:32 +0800 From: Peter Wemm <peter@spinner.dialix.com.au> To: Greg Lehey <grog@lemis.com> Cc: FreeBSD Chat <chat@FreeBSD.ORG> Subject: Re: Bastard System V (Was: Bug in malloc/free) Message-ID: <199709200434.MAA24241@spinner.dialix.com.au> In-Reply-To: Your message of "Sat, 20 Sep 1997 12:51:24 %2B0930." <19970920125124.14990@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote: > (following up in -chat) > > On Sat, Sep 20, 1997 at 11:05:17AM +0800, Peter Wemm wrote: > > Greg Lehey wrote: > >> On Fri, Sep 19, 1997 at 11:49:06PM +0000, Terry Lambert wrote: > >>>>> When a read or write fault occurs on page zero in a program running > >>>>> on SVR4, rather than crashing, they map the page and note the effect. > >>> > >>> [ ... ] > >>> > >>>> It's not just incorrect, it's inconsistent. Some SVR4 do, some SVR4 > >>>> don't. > >>> > >>> Sorry dude, but if it's derived from USL sources, it does this, > >>> unless they've specifically taken it out. > >> > >> If you say so. Then they've specifically taken it out. > > > > Don't forget the mixed lineage of the SVR4 tree. My memory is a little > > vague, but as I understand/remember:- > > > > - AT&T/USL release a native version on the 3b series of machines. > > > > - Intel get hold of it and port it to the 386 (SVR4/386), merging in all > > the Xenix etc stuff from SVR3. I think this was with the involvement of > > Interactive but I don't really know. I suspect this port was where the > > first 'map page zero on demand' behavior happened. Anyway, this was > > handed back to USL or something. > > Xenix was folded in in System V.3.2. I don't know when AT&T moved > their base from 3b2 to i386, but it had happened by the time I did > some courses with AT&T in late 1991. I was under the impression that it happened twice.. The 1989 vintage SVR4 release was 3b specific (I have some AT&T manuals that have 3b console output samples), and it didn't have the Xenix stuff in it as far as I can tell. From what I understand, AT&T did SVR3.0, Intel/Interactive did the the Xenix support and handed it back to AT&T and it was called SVR3.2. Meanwhile AT&T/USG did SVR4.0, and Intel/Interactive/etc merged the SVR3.2 (or was that SYSV R3.2 v2.0?) Xenix stuff forward to the SVR4 base and produced SVR4/386 and again sent it back to AT&T/USG and/or USL (I think USL existed by then). > > - Meanwhile, motorola were porting the 3b code to the 68000 series (Amiga > > UNIX was based on the motorola port which "felt" quite different to the > > SVR4/386 derived code). > > Are you talking SVR3 or SVR4 here? My understanding was that Motorola > never released their SVR4 for their boxes. Maybe they didn't release it commmercially for their boxes, but I'm quite sure they (Motorola) took the 3b base code from AT&T and adapted it to run on mc68K hardware and sent it back to AT&T/USG/USL. This would have probably been the same arrangement as what Intel was working under. (ie: AT&T produce a 3b version, and the processor manufacturers port that to their cpus for other vendors to base from). I was told (by whom I considered a reliable source within the Amiga Unix camp at the time) that the AMIX/Amiga UNIX port was derived from the 3b-> Motorola variant) > > - Somewhere along the way, the SVR4/386 port was adapted to run on the > > i860 series (eg: what was used at PCS for the Firebox(?) etc series). > > > > - Also, the SVR4/386 code was converted to run on the MIPS series > > processors (as used in the SVR4 internals book). When I met one of the > > authors of the book, he had some interesting stories to tell about this. > > Must have been Berny. He was on the same course I mentioned above. > We only had a limited number of places, and the other author (James > Cox) and I had to fight for a place. I won, but I had to promise to > bring back a set of the course material for him. Yep. He spoke about the perils of USL supplying the RCS tree of the SVR4/ mips code which still had functional SVR4/386 code as rev 1.1.... > At this time, we (Tandem) already had a SVR3.2 port on our MIPS boxes. > It was largely derived from RISC/OS. The SVR4 port basically folded > the processor-independent layers of SVR4 onto our SVR3 > processor-dependent code. That may have changed now that Tandem has > released the Puma (and I no longer have the insight into the source > that I would like :-), but I'm sure there's still a lot of stuff in > there from the SVR3 days. Yep, this was what I seem to recall Berny talking about.. I think he said something along the lines of getting the mips code from USL and then taking stuff from their previous releases to make it all work on Tandem hardware.. Or something like that. > >> *All* the SVR4 systems I know deviate elsewhere than the drivers. > > > > You can say that again... :-) They are quite a mixed breed. They vary > > more than the *BSD's. :-) > > > > However, one thing that still suprises me is how well the ABI had stuck. I > > was amazed that I could take a program (perforce client and server) > > dynamically linked for NCR's current x86 SMP system and run it on our old > > 1993 vintage SVR4.0 system without the slightest hiccup. > > You were lucky. A few years back, I tested the first Solaris/86 > stuff, and tried to run UnixWare binaries on it. No go. Hmm.. I recall something to that effect too.. I've got a unixware 1.1.mumble cdrom sitting in a box on a shelf somewhere. I seem to recall that a lot of things in Unixware (SVR4.2) make a lot of calls to the security subsystem. Since this is well outside the original ABI it's not too suprising that it doesn't work too well. :-] The NCR system I was talking about was SVR4.0 derived I think. I suspect the binary interface was expanded in between SVR4.0 -> SVR4.2. Since Unixware is SVR4.2 based and Solaris/x86 is SVR4.0 based with diverging development, probably different syscall numbers etc, It's not real suprising there are problems. NCR seem to have spend a lot of their effort on the SMP aspects of the kernel rather than making the userland stuff diverge. > Greg > Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709200434.MAA24241>