Date: Sat, 20 Sep 1997 12:51:24 +0930 From: Greg Lehey <grog@lemis.com> To: Peter Wemm <peter@spinner.dialix.com.au> Cc: FreeBSD Chat <chat@FreeBSD.ORG> Subject: Bastard System V (Was: Bug in malloc/free) Message-ID: <19970920125124.14990@lemis.com> In-Reply-To: <199709200305.LAA23383@spinner.dialix.com.au>; from Peter Wemm on Sat, Sep 20, 1997 at 11:05:17AM %2B0800 References: <19970920094155.13744@lemis.com> <199709200305.LAA23383@spinner.dialix.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
(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. > - 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. > - 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. 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. > - Meanwhile.. SVR4/386 was being madly polished for retail by the likes of > Dell, ESIX, UHC, etc. They were feeding bugs/fixes back to USL too. One > of these groups may have been the origin of the 'map page zero on demand' > "feature". I know the Dell flavour had it, and I think that ESIX didn't. > It may have been Dell that was responsible for submitting it back to USL in > between the 2.0 and 3.0 USL SVR4.0/386 releases. Possible. I think that Tandem doesn't, but I haven't checked. We had trouble with this as far back as the SVR3.1 days on our 68020 box. > - And then... USL took the SVR4.0/386 code, merged in (or had others > merge in) various things like SMP, nearly-B1 level security etc and came > out with SVR4.2. > > - And then came unixware, then novell bought USL, then SCO bought novell's > unix business including USL and Unixware and now it's supposedly been > merged into SVR5 or whatever. Let the games really begin. > > Anyway, this is definately heading away from freebsd-bugs relevance... > >>> If so, then they are probably paying a huge royalty increment for >>> the priveledge, since you pay more (by a factor of 10) for not being >>> exactly their sources for everything but drivers. >> >> *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. > I suspect this is because the SVR4 libc.so is really a .a file with some > of the components (the ABI core) living in libc.so.1, and the rest in > statically linked .o objects. I disagree with some of the choices (eg: > utmp is outside the ABI, so every program that uses getutent() has a > compiled-in knowledge of the utmp format on that system and cannot work on > another via a different implementation in libc.so.1.) Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970920125124.14990>