Re: [PATCH RFC tools 5/6] tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.

[Ian Campbell <ian.campbell@citrix.com>]

On Wed, 2015-06-10 at 17:29 +0100, David Vrabel wrote:
> On 10/06/15 12:36, Ian Campbell wrote:
> > libxenevtchn will provide a stable API and ABI for accessing the
> > evtchn device.
> > 
> > The functions are moved into the xenevtchn namespace to make a clean
> > break from libxc and avoid ambiguity regarding which interfaces are
> > stable.
> > 
> > All in-tree users are updated to use the new names.
> > 
> > Upon request (via #define XC_WANT_COMPAT_EVTCHN_API) libxenctrl will
> > provide a compat API for the old names, which is used by qemu-xen for
> > the time being.
> > 
> > The dynamic osdep mechanism from libxc is not preserved, the
> > alternative backend (a xen-api/xapi shim) is no longer around. (Nested
> > virt probably suffices for this use case now).
> > 
> > This leaves a few event channel related functions which go via privcmd
> > (EVTCHNOP) rather than ioctls on the /dev/xen/evtchn device in
> > libxenctrl. Specifically:
> > 
> >  - xc_evtchn_alloc_unbound
> 
> I was about to complain that this is important functionality for this
> new lib, but the library provides the more useful
> xenevtchn_bind_unbound_port() instead.  Might be worth mentioning this
> in the commit.

Yes, I hadn't realised the two were redundant in that way. I'll mention
it.

Perhaps we should even consider removing xc_evtchn_alloc_unbound? Other
then the language bindings I can't see an in tree user apart from the
language bindings. I suspect the user was xend.

Ian.