> From: Jason Thorpe <thorpej@nas.nasa.gov>
> Date: Mon, 09 Sep 1996 09:07:08 -0700
> 
> On Tue, 10 Sep 1996 00:14:29 +0930 (CST) 
>  Mark Newton <newton@cleese.apana.org.au> wrote:
> 
>  > Is there any compelling reason why the vmapbuf() routine XXX'ed with
>  > the text, "This implementation is a total crock," shouldn't be replaced
>  > with the (apparently rewritten drop-in replacement) version from the
>  > Amiga, Atari or Mac68k ports?  I'm not suggesting this this'll stop
>  > "everything dumps core," but it's probably worthwhile as a general 
>  > code improvement...
> 
> Heh ... take a look at the mvme68k and hp300 vmapbuf() functions.  
> They're the same as the amiga, but with the orginal comment (i..e. the 
> "total crock" one :-)
> 
> The sun3 version is essentially the same, with two exceptions... the sun3 
> version uses kernel_map instead of phys_map (it _probably_ should use 
> phys_map), and it flushes the VAC on systems that require it (the hp300 
> doesn't have this requirement, since the hp300 pmap cache-inhibits pages 
> which are multiply mapped on the hp320/hp350).

Note, it is not useful for vmapbuf to restrict mappings to phys_map
on the Sun3; the pages need only exist somewhere in kernel space.
The name "phys_map" now means something different on the Sun3, and
is used for DVMA allocations of a small number of pages.

> So, really, dropping in the amiga version verbatim would break the 
> sun3/260 :-)

Right.  The explicit removal of mappings at the pmap layer by vunmap()
causes an implicit flush of the write-back cache for those mappings.
That is important on VAC machines (virtually addressed cache).

Gordon