[ I am the guy who did much of the BSD VM work, so I'll take a stab at this.
  I speak mostly for 4.4, but NetBSD is close enough. ]

> From: Joachim Isaksson <ic@ludd.luth.se>
> Subject: Questions about and suggestions for kernel.
> To: tech-kern@sun-lamp.cs.berkeley.edu
> Date: Wed, 16 Mar 1994 20:55:19 +0100 (MET)
> 
> Since we started the VAX port of NetBSD, a number of questions have appeared,
> along with some suggestions for improving NetBSD. Since we have been looking
> mostly at NetBSD 0.9 and not current, we apologize for anything we 'complain'
> about that might have been improved in the later versions.
> 
> Memory Management
> -----------------
> 
> Q: On what version of the MACH kernel is the virtual memory management based?
> 

The original version came from Mach 2.0 (before external pagers).  Various
portions (e.g. the pmap interface) have been upgraded to 2.5 or 3.0.

> 
> Comment:
> 
>    We have been comparing the MACH 3.0 memory management with the NetBSD 0.9
>    version, and the MACH kernel's code for memory management seems much simpler.
>    Has there been any discussion about updating the memory management in NetBSD?
>    This would probably also improve the portability of NetBSD, the pmap module
>    in the 0.9 version (which as far as we can see is basically unchanged in 
>    current) is rather unstructured and seems to contain parts that are machine
>    independent, and really should be in the generic part of the code.
> 

Simpler?  You must be looking at a whole different Mach 3.0 than I am
familiar with!  The addition of the asynchronous external memory management
interface (not to mention the NORMA extensions) make Mach way more complex
in my estimation.  There are some cleanups that would be good to pick up,
e.g. elimination of sharing maps, but I'm not sure that converting to 3.0
VM is the way to go.  For one thing, you would need to pick up Mach IPC to
make it work well.  At that point I would ask, why not just run Mach?

Re: the pmap module, I assume that by "parts that are machine independent"
you mean things like the pv_table to do physical to virtual translations?
If so, you will note that Mach pmaps look much the same, a lot of replicated
code.  At the time Tevanian did the original interface 7-10 years ago he
was striving for a lowest common denominator (i.e. the Vax :-) and tried not
to assume to much.  Now with the benefit of 10 years of hindsight, the pmap
interface might look much different.  As to the "unstructured" nature, if
you are refering to the i386 module which was derived from the hp300 version
I did, then I agree!  It was a bizzare experiment and it does things that
any self-respecting pmap module probably wouldn't--in particular, its whole
recursive structure and use of the higher level VM.

At any rate I would be curious to hear more details about what you find
particularly obnoxious about the current VM (you won't have to dig too deep!)
I put my 4.4 VM "TODO" list out on sun-lamp:~hibler/TODO.vm if you are
interested.

> Q: Is there any documentation for how it 'should' work or is the source the only
>    available documentation?
> 

I never really wrote up anything for it.  You might get a copy of:
	"Architecture-Independent Virtual Memory Management for Parallel and
	Distributed Environments: The Mach Approach", Avadis Tevanian, Jr.,
	December 1987, CMU-CS-88-106
which was Avie's thesis describing the 2.0 vintage VM system.

...

> Comment:
> 
>    At least some support is there, in the MACH memory management code, but what
>    is the status of the rest of the kernel? We have two VAX8350 here with 2 cpu
>    each, and it would be interesting to know how we can make them usable with
>    NetBSD.
> 

I left the MP support in the VM code under the assumption that BSD would be
MP-safe at some point (even if at a very course granularity).  Even though
I have tried to continue thinking about MP issues whenever I added/changed
something, I doubt I did a very good job so even the MP-ness of the VM code
is suspect.

------------------------------------------------------------------------------