[Xen-devel] [PATCH v3 0/<VARIOUS>] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

In <1431963008.4944.80.camel@xxxxxxxxxx> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.

This is v3 of that set of series against:
    xen
    qemu-xen (new this time)
    qemu-xen-traditional
    mini-os

NB: minios-devel will only get the mini-os side and Stefano the qemu-xen
side.

The code in for all repos can be found in:

git://xenbits.xen.org/people/ianc/libxenctrl-split/xen.git                  v3
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.git             v3
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git v3
git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.git              v3

(nb the repos have changed since last time, I've carried the v2 tags over
as well)

The tip of the xen.git branch contains an extra patch adding a .config
into the tree which should get the correct things for the HEAD of the
branch, but not further back.

The new libraries here are:

 * libxentoollog: Common logging infrastructure
 * libxenevtchn: Userspace access to evtchns (via /dev/xen/evtchn etc)
 * libxengnttab: Userspace access to grant tables (via /dev/xen/gnt??? etc)
 * libxencall: Making hypercalls (i.e. theÂIOCTL_PRIVCMD_HYPERCALL type
   functionality)
 * libxenforeignmemory: Privileged mappings of foreign memory
   (IOCTL_PRIVCMD_MMAP et al)

The first three were actually pretty distinct within libxenctrl already and
have not changed in quite some time.

Although the other two are somewhat new they are based on top of long
standing stable ioctls, which gives me some confidence.

Nonetheless I would appreciate extra review of at least the interface
headers of all of these with a particular eye to the suitability of these
interfaces being maintained in an ABI (_B_, not _P_) stable way going
forward.

Still to come would be libraries for specific out of tree purposes
(device model, kexec), which would be adding new library at the same
level as libxc I think, rather than underneath, i.e. also using the
libraries split out here, but hopefully not libxenctrl itself.

The new libraries use linker version-scripts to hopefully make future
ABI changes be possible in a compatible way.

Since last time I have:

 * Moved everything from tools/libxenfoo to tools/libs/foo
 * Added patches to qemu-xen to use the new libraries instead of the compat
   layer. These can come any time after this transition and are not
   entangled (due to the compat layer being present in the meantime)
 * Reviewed each of the new libraries for
    * Error handling, Specifically no return -errno type stuff, but instead
      return -1 or NULL and setting errno if necessary
    * Appropriate types (some discussion around that hasn't been folded in
      here yet)
    * No inlines in the pubic headers (troublesome for ABI compatibility)
    * Documentation, in that they all have some, not that it is necessarily
      comprehensive or complete (although it does look better than the
      average).
 * DroppedÂ
   Âand you
   can find its history
 * Fixed various issue.

The whole thing has been build and runtime tested on Linux and stubdoms,
and built (but not run) on FreeBSD. Neither NetBSD nor Solaris have been
tested at all. It's certainly not impossible that I've not got the
#includes in the new files quite right.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel