🚀 go-pugleaf

>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.

Whilst I would not argue that support for a new MMU trivially plugs into
the SunOS 4.0/S5R4 VM system, with the SunOS 4.0 VM architecture the
ripples don't go as far as they do in some other systems; support for
the "standard" Sun MMU, the 68030 on-chip MMU, the 80386 on-chip MMU,
and now the Campus-1 err sorry SPARCStation-1 MMU (4KB pages, rather
than 8KB pages, as in the standard Sun-3/Sun-4 MMU) fit in fairly
cleanly. 

I think Mach is also supposed to be set up to cleanly support a variety
of MMUs as well.  I think it's been ported to machines with
"conventional" N-level page table MMUs, Sun-style static-RAM MMUs, and
"inverted page table" MMUs (is not the IBM RT PC's MMU of this type?). 
The SunOS 4.0 one hasn't been ported to the latter, yet, as far as I
know; I don't know how difficult it would be.

I assume one of the goals of IBM's VM modifications in recent or
forthcoming AIXes is similar (since they have to support the RT PC,
80386, and 370 - and, presumably, since OSF plans to pick up the AIX
kernel, right? they also will have to support the VAX and MIPS MMUs, and
Apollo's MMU(s?), and HP's, and...).

So, whilst I'll agree that it's not necessarily the case that "A well
written operating system only requires a change to a single driver to
port it to a new MMU.", a well-designed VM system can handle a fairly
wide range of MMUs with pretty localized changes to VM code.