[Qemu-devel] [Minios-devel] [PATCH v6 0/<VARIOUS>] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell <ian.campbell@citrix.com>]

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

This is v6 of that set of series against:
    xen
    qemu-xen
    qemu-xen-traditional
    mini-os

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

The code for all repos can be found in:

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

The tip of the xen.git branch contains an extra patch hacking Config.mk
to point to all the others above, which should get the correct things for
the HEAD of the branch, but not further back in time.

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:

 * Major changes to the libxenforeignmemory interface, which necessitated
   some changes on the qemu-xen side too, invalidating various
   (Ack|Review)ed-by.
    * Reordered the arguments to make the use of VLA possible in the future
      
    * Allow err==NULL, this in turn lead to the realisation that the error
      handling for a bunch of the xc_map_foreign_* functions which
      transition => xc_map_foreign_bulk => xenforeigmemory_map in this
      series was all wrong in expecting a NULL return on error when errors
      can also be signalled in err[]. This lead to most of the dropped acks
      and various reorderings/restructuring of changes 
 * Lots of docs updates based on feedback given, especially to the gnttab
   interface.

Even with the dropped acks mini-os and qemu-xen-trad are fully acked, while
qemu-xen and xen are mostly acked (but had a few dropped acks since last
time).

The whole thing has been build tested on Linux (incl stubdoms), and on
FreeBSD. I have runtime on Linux with qemu-xen, qemu-xen-trad and stubdoms.

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.

http://xenbits.xen.org/people/ianc/libxenctrl-split/v6.html is the document
I've been using to try and track what I'm doing. It may not be all that
useful. The history of it is in the v6-with-doc branch of the xen.git
linked to above.

Last time  proposed that these precursors (and the corresponding qemu-xen-
traditional + mini-os patches) should go in now:

    tools/Rules.mk: Properly handle libraries with recursive dependencies.
    tools: Refactor "xentoollog" into its own library

But I subsequently found a couple of build issues, which are addressed by
two new patches at the head of the xen series.

Note also that I've picked up "x86/libxc: add an arch domain config
parameter to xc_domain_create" into my xen branch, in order that I can work
against qemu mainline, I expect that to go in shortly and be dropped here
(just waiting on a qemu-xen-upstream-unstable osstest pass).

Ian.