Re: pmap_extract(9) (was Re: xmd(4) (Re: XIP))

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Mon, Nov 08, 2010 at 03:22:42PM +0000, Eduardo Horvath wrote:
> On Mon, 8 Nov 2010, Masao Uebayashi wrote:
> 
> > On Fri, Nov 05, 2010 at 05:36:53PM +0000, Eduardo Horvath wrote:
> > > On Fri, 5 Nov 2010, Masao Uebayashi wrote:
> > > 
> > > > On Mon, Nov 01, 2010 at 03:52:11PM -0700, Matt Thomas wrote:
> > > 
> > > > > Indeed.  Also consider that pmap's are designed to have to have
> > > > > fast V->P translations, using that instead of UVM makes a lot of
> > > > > sense.
> > > > 
> > > > How does locking works?
> > > > 
> > > > My understanding is page tables (per-process) are protected by
> > > > struct vm_map (per-process).  (Or moving toward it.)
> > > 
> > > No, once again this is MD.  For instance sparc64 uses compare and swap 
> > > instructions to manipulate page tables for lockless synchronization.
> > 
> > I don't like "it's MD, period" attitude.  That solves nothing.
> 
> Yes it does.  If you have bleed through between the different abstraction 
> layers it makes implementing a pmap for a new processor much more 
> difficult and makes the code inefficient since you end up implementing a 
> whole bunch of goo just to keep the sideffects compatible.  You should not 
> be making any implicit assumptions beyond what is explicitly documented in 
> the interface descriptions otherwise the code becomes unmaintainable 
> across the dozens of different processors and MMU archittures we're trying 
> to support.

Most of pmaps are already almost unmaintainable IMO. ;)