From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH RFC tools 5/6] tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn. Date: Thu, 11 Jun 2015 10:03:12 +0100 Message-ID: <1434013392.30003.133.camel@citrix.com> References: <1433936188.30003.60.camel@citrix.com> <1433936205-21539-5-git-send-email-ian.campbell@citrix.com> <557870FD.9030007@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <557870FD.9030007@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: wei.liu2@citrix.com, roger.pau@citrix.com, ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 > > --- > > > > 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.