🚀 go-pugleaf

in article <232@ross.UUCP> doug@ross.UUCP (doug carmean) writes
> In <3390@orca.WV.TEK.COM> Andrew Klossner writes
> >An MMU is not a "device," to be "driven" easily by a single module.
> >Big MMU differences cause ripples throughout the kernel, and in extreme
> >cases can affect user code.

> Notice that my posting stated that a "well written operating system requires
> a change to a single driver...".  By well written I was referring 
> specifically to SunOS, which requires very minor modifications to be ported
> to a new MMU.  All of the code specific to the MMU is localized in
> a single routine, not scattered throughout the kernel.  A new MMU will
> not affect user code even in the extreme cases.

this is untrue even for sunos.  to accomodate the new mmus for the
3/80 and sparcstation, sun has different kernels for the new machines.
new versions of the operating system provide the -k flag to arch which
will print sun3 and sun4 for old machines and sun3x and sun4c for new
ones.  libkvm.a runs different code to grub through the kernel depending
on which mmu is used, and i believe different versions of ps and friends
are needed for the different kernel architecures.

the hat layer in sunos 4.0 does provide some distance between the
mmu and the rest of the kernel, but some decisions are pervasive.
for example, the layout of the u area is affected by the size of
page tables, which depends on the page size.

some user code is sensitive to machine page size, sometimes for
performance, sometimes for functionality.

paul haahr
haahr@princeton.edu princeton!haahr