Re: [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Cc: minios-devel@lists.xenproject.org,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries
Date: Wed, 15 Jul 2015 16:53:16 +0100	[thread overview]
Message-ID: <55A681EC.2050508@citrix.com> (raw)
In-Reply-To: <1436975173.32371.121.camel@citrix.com>

On 15/07/15 16:46, Ian Campbell wrote:
> (this is clearly not 4.6 material, aiming for 4.7)
>
> In <1431963008.4944.80.camel@citrix.com> I proposed stabilising some
> parts of the libxenctrl API/ABI by disaggregating into separate
> libraries.
>
> After the previous proof of concept I have now split out:
>       * xentoollog
>       * evtch
>       * gntdev and gntshr
>       * hypercalls
>       * privileged foreign memory mappings
>
> These represent the core low level functionality which everything else
> needs, I think, and so are moving things down into a layer below libxc
> (i.e. libxc uses all of these).
>
> There are 3 series, against xen.git (15 patches), mini-os.git (5
> patches) and qemu-xen-trad.git (5 patches). The patches against xen.git
> point to the patches in the other two trees via instructions to update
> the relevant Config.mk field. The perils of changing unstable
> interfaces!
>
> NB: minios-devel will only get the mini-os side.
>
> The code in for all three can be found in:
> git://xenbits.xen.org/people/ianc/xen.git               libxenctrl-split-v2
> git://xenbits.xen.org/people/ianc/qemu-xen-unstable.git libxenctrl-split-v2
> git://xenbits.xen.org/people/ianc/mini-os.git           libxenctrl-split-v2
>
> 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.
>
> 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.
>
> I'm stilling mulling over putting everything into tools/libs/FOO
> instead of tools/libxenFOO

On balance, +1.  tools/ is already quite a mixed bag of stuff.

> , I still haven't but I could if people think
> it is worthwhile. Eventually I'd like to split libxc into libxenguest
> and libxenctrl to cut down on the amount of strange cross talk...

Very much +1.

FWIW, also splitting xl and libxl into different directories.

~Andrew