> > > > > OK, I finally found where it mmaps /kern/xen/privcmd. MAP_ANON seems
> > > > > to work equally well, so I fixed this in pkgsrc.
> > > > 
> > > > then, old xentools binaries doesn't work on -current
> > > > (and netbsd-3 once pulled up) anymore?
> > > > 
> > > > i guess it's a good chance to change IOCTL_PRIVCMD_INITDOMAIN_EVTCHN
> > > > without compatibility considerations :-)
> > > 
> > > The problem isn't that simple. The new tools will work with an older kernel.
> > > In the IOCTL_PRIVCMD_INITDOMAIN_EVTCHN case it's not the case (old tools/new
> > > kernel and old kernel/new tools won't work), so some kind of compat is needed
> > > to ease the transition.
> > 
> > is it (new userland + old kernel) expected to work?  i don't think so.
> 
> In this case it's not "new userland", it's a software from a newer pkgsrc
> built on an older system.

sorry, i don't understand your point.
xentools is an userland application.
any userland applications which rely on something new in kernel are not
expected to work with older kernel.
whether it's in basesrc or not is not related.

> The upgrade path for the /kern mmap issue is:
> update pkgsrc and rebuild xentools20
> update kernel
> reboot
> if something goes wrong with the new kenrel you can still go back to the
> old one.

you can go back to the old xentools, can't you?

YAMAMOTO Takashi