> On Sun, Dec 02, 2007 at 12:03:15AM +0900, YAMAMOTO Takashi wrote:
> > > > > This doesn't fix the problems with the
> > > > > ioctl,
> > > > 
> > > > the problem with the ioctl is that it replaces the existing mapping.
> > > > if you mmap the device, you can control the existing mapping.
> > > > 
> > > > > and introduce some more issues (like, we can't provide physical
> > > > > addresses to udv_attach() or udv_fault() because these are not physical
> > > > > adresses, and we don't even have them at the time of mmap).
> > > > 
> > > > as far as ioctl does pmap_enter_ma by itself, udv_fault implies
> > > > an error of user.
> > > 
> > > But if the ioctl does pmap_enter_ma() by itself, the vm_map won't have
> > > the appropriate infos, isn't it ? Especially, uvm won't known that
> > > this range is really mapped, and I suspect accounting will be wrong.
> > 
> > which accounting are you talking about?
> > basically uvm doesn't track mapping of individual pages.
> > pmap does, but it's MD and under your control.
> 
> Doesn't it have a uvm_page for each page in the (user) pmap, even thoses
> backed by an uvm_object ?

in this case, no.

> > > > it isn't the first time this interface is changed without keeping
> > > > binary compatibility.  (it's a little ironic that this "replace anonymous
> > > > mapping" thing was introduced by the last change which didn't keep binary
> > > > compatibility.)
> > > 
> > > AFAIK this interface didn't change since I got xentools working. Old
> > > xentools20 should still work with netbsd-4, and even current if the pthread
> > > issues can be worked around.
> > 
> > it depends on how old "old xentools20" is.  see UPDATING rev.1.140.
> 
> But it was in current, not in a release branch. 

i'm not sure how/which pkgsrc version is tied to netbsd releases.

YAMAMOTO Takashi