On Thu, 25 Mar 1999, Charles M. Hannum wrote:

> * The copy-on-write checks in uvm_fault() force the page to be mapped
>   with just PROT_READ.  This may also cause any particular pmap
>   implementation may cause the page to also be non-executable.  This
>   would be poor; we'd end up taking another fault and going through
>   uvm_fault() again, even though no copy-on-write action needs to be
>   performed.
> 
>   (I don't think there are any pmaps which currently maintain the read
>   and execute bits separately, though some of them certainly could.)

Machines with separate DMMU/IMMUs could map pages only into one of them to
provide separate execute permissions.  (I was considering this but decided
it made debugging more complicated if you can't disassemble your text 
sections.  I may still do this eventually to reduce MMU TLB footprints.)

> * If file system buffers were mapped using pmap_enter(), they would
>   not actually be accessible yet, due to the R/M emulation.  Since
>   they are then pagemove()d behind the pmap's back, the R/M emulation
>   state got highly confused, and this caused substantial lossage.  The
>   Alpha port slinks around this by using pmap_kenter(), which
>   explicitly does not do R/M emulation.  Using the new `fault type'
>   argument to pmap_enter(), I have arranged for the buffers to always
>   be immediately accessible, so it is not necessary to use
>   pmap_kenter().
> 
>   (Indeed, this may obviate the `need' for pmap_kenter() completely.)

If you plan to change the interface to pmap_enter() please make it take an
additional size argument so we don't have to change it again for future
large-page support.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me