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 ?

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

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