Date: Sat, 20 Sep 1997 11:05:17 +0800 From: Peter Wemm <peter@spinner.dialix.com.au> To: Greg Lehey <grog@lemis.com> Cc: Terry Lambert <tlambert@primenet.com>, nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free Message-ID: <199709200305.LAA23383@spinner.dialix.com.au> In-Reply-To: Your message of "Sat, 20 Sep 1997 09:41:55 %2B0930." <19970920094155.13744@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. - 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). - 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. - 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. - 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. 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 Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709200305.LAA23383>