> But, you are seriously deluded if you think it wouldn't be very much
> work.  They went through several weeks of almost unrunnable systems
> when the latest mega-merge of their VM code made it into the tree.
> And they already had the base code established.
>
I understand the VM system as well as anyone -- and to say that changes
can be made without very careful review is folly -- I regularly make
fatal mistakes.  Michael is VERY VERY correct above.

> 
> You also have to remember that everything you do needs to run on all
> NetBSD platforms, not just Intel.  Their code is not written with that
> in mind.
> 
The biggest issue is that I haven't recently reviewed the code
for architectures w/o reference and/or modified
bits.  Should work (with a couple of strategically placed ifdefs in the
upper level code), but haven't checked it recently.  Also, alot of the
work has been at the pmap layer, where very significant improvements
have been made recently.  (Pmap has had several severe structural flaws
since day one.)  Pmap is of course intrinsically machine dependent.
Another major issue is that we currently have no support for PAGE_SIZE
> MACHINE_PAGE_SIZE.  That is of course bad for arch's like VAXen.

I would suggest that a gradual movement from the original VM code to the FreeBSD
code would be in order.  During the movement, you would have a chance to
do a careful design review and feed back problems and comments to your's
truly... :-).  We could both then benefit, and probably end up with better
code than FreeBSD currently has.  A flash-cut would certainly be a challenge
(considering all of the collateral changes.)  Debugging a totally broken
system, not understanding all of the dependencies is NOT FUN...

John