> > > 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.

> > i personally don't think it's worth to keep bug-to-bug compatibility for
> > this.  if it was for a linux-compatibility thing which we can't
> > control, i can understand.  but it's a netbsd specific interface.
> 
> For which we have existing binaries.

sure.

> > 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.

YAMAMOTO Takashi