Porting AT&T System V Release 4 to multiple cpus

[Keith Gabryelski]

In article <5032 at auspex.auspex.com> guy at 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