On Wed, 23 Oct 1996 17:05:34 -0700 (PDT) 
 Jeremy Cooper <jeremy@broder.com> wrote:

 > You are absolutely correct!  The amiga and hp300 port use the 68030 ATC as
 > well.  In fact, they both use the same MMU code which came with the hp300
 > port.  However, there's been a desire for a cleaner MMU management code.

Yah, a nicer pmap would be cool...

 > The hp300 MMU code (which is officially called the 'pmap' module in
 > NetBSD) is really a bizarre sort of hack.  Even Jason, who manages the
 > hp300 port agrees.

Well, there are several places where it could be improved, sure... I don't
recall saying it was a bizarre sort of hack, but whatever :-)

Anyhow, the name `pmap' actually comes from Mach, which is where the 4.4BSD
VM system comes from.  OSF/1 has a pmap, NeXTstep has a pmap, etc.

On many systems, the pmap does more than just frob with the MMU.  Sure,
it sets of the segment and page tables, etc.  But, the pmap is defined 
as the layer of VM code that manages physical pages... That's why you have
things like pmap_copy_page() and pmap_zero_page().

 > The problem deals with its dependency on other parts of the kernel in its
 > operation.  Ideally, the pmap code should be able to run independently of
 > the other parts of the kernel; it should not rely on other kernel
 > subsystems (like virtual memory management) to do its job because often,
 > these subsystems depend on the pmap code to do theirs!  This means that
 > the pmap code must be re-entrant and that it also know the consequences of
 > calling the other parts of the kernel.  Should these intracacies change,
 > it could be very hairy trying to fix the pmap code to handle these new
 > changes. 

Yah, this is a sticky thing to deal with.  However, you get to a point
where calling other parts of the kernel might become convenient.  For
example, you may want to be able to page e.g. the user pt maps, so that
they don't chew up large amounts of memory (right now, that memory is
wired down, ick).

 > As to the second part of your question, one major difference is how DMA is
 > handled.  The sun3x has a special piece of hardware called the "I/O
 > Mapper" which handles DMA to virtual memory.  Generally, the sun3x port is
 > going to be an easier port because the machine was designed from the start
 > to run UNIX.  The Mac port probably was a, well, insert your favorite
 > explative here.

Ah, so that's how they did DVMA... cool.  That sounds almost like the
Sun4m iommu...

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939