Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.sys.m88k
Subject: Re: Shrink-wrap UNIX for 88open architecture.
Message-ID: <7468@auspex.auspex.com>
Date: 27 Apr 91 20:46:12 GMT
References: <4155@risky.Convergent.COM> <2540@urbana.mcd.mot.com> <10690@orca.wv.tek.com>
Organization: Auspex Systems, Santa Clara
Lines: 33

>	"I think that it would be well within the relm of possibility
>	to issolate the machine dependent parts of the kernel in to a
>	well defined module which would then be vendor specific."
>
>We tried to do this.  Spent great gobs of money, ended up with failure
>-- the task turned out to be much bigger than initially estimated.

You may find that S5R4 does a better job of that than S5R3 did; I'm
assuming the UNIX system for which you tried doing that was S5R3-based.
For example, S5R4 has a Sun-style VM architecture, with the MMU support
much better centralized (the difference between the last S5R4 load with
the old VM stuff, and the first load with the new VM stuff, with regard
to how much MMU dependencies permeated the system was huge).  S5R4 may
still not do it as well as it could, but it probably does it better;
pressure should be applied to USL to improve S5 if there are areas where
it doesn't isolate machine-independent and machine-dependent parts of
the system (not just the kernel) as well as could be done.  (For one
thing, it'd probably be wise for all the ports that are "owned" by USL
to come from *one* source tree; I very much doubt that "cat" needs to
differ on different platforms, for example.)

OSF/1 will probably be similar, at least in the MMU area; Mach has a
similar notion of a "pmap module" for handling the MMU.

>A major problem is that releases of standard Unix come out so fast that
>you couldn't keep up with them with this scheme, unless you had a lot
>of resources to spend on the problem.  And the payback isn't enough to
>spend those resources.

The organizations that spend those resources should be the vendors of
"porting base" systems, e.g. USL, OSF, etc., so that the releases of
standard UNIX already fit that scheme and the purchasers of those
systems don't have to run around trying to fit them into that scheme.