Subject: Re: remplacing page mappings behind uvm
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 12/02/2007 00:03:15
> > > 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.
> > 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.