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

[Andrew Cooper <andrew.cooper3@citrix.com>]

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.

For xenevtchn, it is never realistically going to gain logging.  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.

~Andrew