> Date: Fri, 15 Nov 1996 17:20:17 -0500
> From: Chris G Demetriou <Chris_G_Demetriou@ux2.sp.cs.cmu.edu>

> > Note that the code for the MACHINE_NONCONTIG
> > case isn't any easier or harder than the old case, just different.
> 
> This isn't true.
> 
> in the (!MACHINE_NONCONTIG) case, the MD pmap code sets a few
> variables, has to implement pmap_bootstrap_alloc(), and calls the MI
> VM code.  "done."
> 
> In the MACHINE_NONCONTIG case, the MD pmap code has to (at least)
> implement pmap_free_pages(), pmap_virtual_space(), and
> pmap_next_page(), and may also want to implement two more functions.
> 
> 
> Essentially, pmap_virtual_space() does some of the the
> variable-setting, pmap_free_pages() tells how many pages are available
> to the VM system (which corresponds to most of the rest of the
> variable-setting done in the !MACHINE_NONCONTIG case), but
> pmap_next_page() actually does work (getting the next free page) which
> is done by MI code in the !MACHINE_NONCONTIG case.  It actually does
> push functionality down into the MD code.
> 
> Those functions aren't "hard" to implement, but it's easier to
> implement the !MACHINE_NONCONTIG case, especially if the added
> functionality provided by MACHINE_NONCONTIG really isn't needed.
> 
> cgd

We could solve that problem by providing a file that implements a
compatibility layer to help contiguous memory machines work with
the new (non-contig) interface.   The new functions required by
the non-contig interface are quite trivial in the contig case.

Gordon