[rescue] DEC keyboards

[Jonathan C. Patschke]

On Wed, 15 Nov 2006, Jochen Kunz wrote:

> NetBSD has split most of this in MI (machine independent) and MD
> (machine dependent) parts. E.g. uvm(9) (memory manager) has a MI core
> that interfaces to a (comparatively small) MD backend, caled pmap(9).
> So most of the memory management is MI.

The virtual side of it, sure, but the bits that actually frob the MMU
and manage caching are the important parts, and they're always going to
be MD.

>> In this sense, portability grows out the barrel of an #ifdef.
> NetBSD can deal with all of those differences without #ifdefs.

Without them literally, but the idea is the same.  Different code is
executed on different platforms, whether that happens inside the driver
itself or inside some deeper abstraction barrier isn't entirely
relevant.  I dealt with the BSD bus.h stuff a while back, and, at least
then, even drivers that claimed to be fully reliant on the bus
abstraction code still had system-specific bits in them from time to
time.

The point I'm getting at is that applications can be ported--provided
that the underlying OS and C RTL of the new system support the same
entry points as the original system, the application can be reasonably
said to run the same code in both places.  Even if they're only slightly
different, the application is mostly portable, since almost all the same
application-side code is run everywhere.  As you try to run on wildly
different systems (win32 vs. Unix), the layer of compatibility sludge
gets thicker, and, at some level, you're reimplementing more and more of
the app in the compatibility layer to call what's left of the
application "portable".  In reality, you've reduced the size of the
original application and have written a set of nonportable applications
to support it in various places.

For some applications that survive the Unix->Windows or VMS->Unix
transition, there's only a central library comprising the portable bits,
with all the rest of the application supporting the operating
environment (Mathematica comes to mind as a good example; the MathKernel
is reasonably portable, but the frontend is reimplemented everyplace).

With OSes, the amount of compatibility code is immense; huge stacks of
code might not even be run (or, indeed, present in the binary) on one
system, whereas they might comprise an appreciable amount of machine
time on another (parts of the bus-handling code, for instance).  At that
point, calling the OS on those two wildly different systems "the same"
is a bit laughable.

-- 
Jonathan Patschke  ) "Some people grow out of the petty theft of
Elgin, TX         (   childhood.  Others grow up to be CEOs and
USA                )  politicians."              --Forrest Black