Re: Unifying /dev/{mem,kmem,zero,null} implementations

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

> Joerg Sonnenberger wrote:
> > On Sun, Feb 24, 2008 at 12:40:51AM +0000, Chris Gilbert wrote:
> >> The documentation says every pmap_kremove needs a pmap_update, relying on 
> >> something later on doing a pmap_update is risky.
> > 
> > Not here. The address is used strictly for one purpose and a CPU can
> > only use it when holding the mutex. So the pmap_update after
> > pmap_kremove shouldn't be needed.
> > 
> >> In theory pmap_kremove could be optimised to not change anything in 
> >> hardware, and defer the work to be done till the pmap_update, while I 
> >> don't 
> >> believe any platform has gone to that level yet, we shouldn't exclude the 
> >> possibility by not following the documented API.
> > 
> > I don't read the documentation that way. pmap_update will happen at a
> > later point anyway and that should be good enough.
> 
> pmap(9) man page for pmap_update says:
> 
> This routine must be used after calls to pmap_enter(), pmap_remove(), 
> pmap_protect(), pmap_kenter_pa(), and pmap_kremove() in order to ensure 
> correct operation of the virtual memory system.

it doesn't say "immediately after".

YAMAMOTO Takashi

> 
> Perhaps I'm being pedantic but that says pmap_update is needed.  If we 
> want to make it optional we should probably state it explicitly, or 
> perhaps make platforms flush kernel pmap updates out before going back 
> to userland.
> 
> I guess my concern is that people like to copy existing code, and it 
> might get missed when it is actually important.
> 
> Thanks,
> Chris