On Sat, Dec 01, 2007 at 11:27:11PM +0900, YAMAMOTO Takashi wrote:
> > On Sat, Dec 01, 2007 at 10:23:40PM +0900, YAMAMOTO Takashi wrote:
> > > i think the easiest fix for the problem which started this thread
> > > is making libxc (back) to use non-anonymous mapping.
> > > as far as you mmap a valid object (either kernfs file or device,
> > > i prefer the latter), uvm_unmap calls pmap_remove for you.
> > 
> > I agree that we should have a valid object (at last a valid map entry,
> > which, as things are now, probably means a valid object). But I'm not sure
> > at all that mmaping a device to get the object at mmap time rather than
> > ioctl time makes things easiers.
> 
> it makes things easier because we don't need to make vm provide
> a functionality to replace existing vm entries.

I'm not sure we can avoid it

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

> > 
> > -- 
> > Manuel Bouyer <bouyer@antioche.eu.org>
> >      NetBSD: 26 ans d'experience feront toujours la difference
> > --
> 
> 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.

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

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--