Subject: Re: vmstat, iostat etc no longer work?
To: None <>
From: Wolfgang Solfrank <>
List: current-users
Date: 11/15/1996 14:37:11
> mac68k kernels cannot compile without MACHINE_NONCONTIG. 
> As I don't know exactly what this option is all about, I cannot tell
> whether or not all Macintoshes must have MACHINE_NONCONTIG defined.
> Note just for mac68k: If in fact this option is required for all Macs,
> I'll propose that this option be moved from the individual kernel
> configurations to std.mac68k. 

MACHINE_NONCONTIG is an option only for the port maintainer (at least I'm not
aware of a port that would work with AND without MACHINE_NONCONTIG).  I.e.
whether to use MACHINE_NONCONTIG or not changes some internal interface between
the machine-independent and machine-dependent code parts of the kernel (see
below for a more complete description).

> If someone can explain the purpose of MACHINE_NONCONTIG to me in a few
> words, please do :) 

The code that now lives in #ifdef MACHINE_NONCONTIG was introduced to support
machines with holes in their physical memory space (e.g. the hole on i386
machines between 640K and 1M, but also holes that result from the physical
memory of machines being divided in banks that have a fixed size, but allow
various memory modules).  The relevant code was more or less stolen from the
Mach3 VM system.  This change required some modifications to the interface
between the machine-independent (the vm code) and the machine-dependent part
(the pmap code) in the kernel.

So when I made the change, I didn't do it in the form it is now, but had only
the code that is now under MACHINE_NONCONTIG.  I made the modified vm code
with the corresponding modifications to the i386 pmap module available to
developers, but didn't integrate it into the tree, in order to encourage them
to turn over the other ports to the new model, too (there were a lot less
ports then...).  Unfortunately pressure mostly from i386 users led to the
current situation, where the new code is under an #ifdef, and there is no
real incentive for port maintainers to switch to the new code.  Even worse,
new ports may start with the non-MACHINE_NONCONTIG case, so the chance of
this define to vanish decreases.  Note that the code for the MACHINE_NONCONTIG
case isn't any easier or harder than the old case, just different.

Maybe this should be stated more prominently in order to at least encourage
new porters to code for the MACHINE_NONCONTIG case instead of the old one.
This would probably require some hints document for new porters, which probably
would be a good thing anyway (NO, I'm not volunteering!).
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800