Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!ag From: ag@cbmvax.commodore.com (Keith Gabryelski) Newsgroups: comp.unix.misc Subject: Re: Porting AT&T System V Release 4 to multiple cpus Message-ID: <17125@cbmvax.commodore.com> Date: 5 Jan 91 00:26:11 GMT References: <16951@cbmvax.commodore.com> <5032@auspex.auspex.com> Reply-To: ag@cbmvax.commodore.com (Keith Gabryelski) Organization: Commodore-Amiga Unix; West Chester, PA Lines: 39 In article <5032@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>There is still a lot of code that is shared. > >But there probably should be more code that's shared; what stuff got >added to the stream head on the 386 port, and what is the justification >for adding it only on the 386? The code added to the 386 stream head was placed there to handle the way they delt with the graphics hardware in release 3 (binary compatibilty). >And there are other cases of bogusly unshared code: > >Did they fix "setregs()" so that the ONLY thing it does is the >machine-DEPENDENT portion of post-"exec" initialization - >[...] setregs() doesn't seem to do anything unreasonable in the current release. >Did they get rid of the notion of starting process 1 by copying a small >lump of machine-language code into the data space and jumping to it, and >instead do it SunOS-style, by faking an "execve()" call (which means >that you can print an error, instead of having the lump of code loop >infinitely, if it can't get "/sbin/init", and also means that you can >pass arguments, such as the "-s" argument which, in SunOS, means you >booted the system single-user; the S5 "init" could be tweaked to do a >more BSDish form of booting)? This hasn't been delt with, although I agree that error messages would be a win. >At least the new VM subtantially reduced the extent to which machine >dependencies permeate essentially machine-independent code.... But breaks in a lot of cases (see previous discussion on fork() returning EAGAIN when physical memory runs low.). Pax, Keith