[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC tools 5/6] tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |