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 18:16 +0100, Andrew Cooper 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
> >  - xc_evtchn_reset
> >  - xc_evtchn_status
> >
> > These functions do not appear to be needed by qemu-dm, qemu-pv
> > (provision of device model to HVM guests and PV backends respectively)
> > or by libvchan suggesting they are not needed by non-toolstack uses of
> > event channels. QEMU does use these in hw/xenpv/xen_domainbuild.c but
> > that is a "toolstack use".
> >
> > The new library uses a version script to ensure that only expected
> > symbols are exported and to version them such that ABI guarantees can
> > be kept in the future.
> >
> > Build tested with Linux and mini-os/stubdom, but not FreeBSD, NetBSD
> > or Solaris.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >
> > Must be applied with:
> >
> >  - "qemu-xen-traditional: Use libxenevtchn" and a corresponding
> >    QEMU_TAG update folded here.
> >  - "mini-os: Include libxenevtchn with libxc"" and a corresponding
> >    bump to MINIOS_UPSTREAM_REVISION folded in here.
> > ---
> 
> As we are taking the hit of updating all in-tree users, and providing a
> compat shim, can we take the opportunity to make amends to the ABI.

Yes, we should in general take the opportunity.

In particular fixing the error reporting behaviour would be a very good
idea...

> For xenevtchn, it is never realistically going to gain logging.

I thought about this but I wasn't sure and at least the Solaris backend
does log (or tries to, who knows if it works!).

>   It
> seems like it would be a good idea to ditch all knowledge of xentoollog
> from the new library, as the cost is just dropping one parameter in the
> callsites.

I don't think the overhead of an extra NULL is worth it, and it's
possible something might want to log there in the future.

Ian.