From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper 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 Message-ID: <55A681EC.2050508@citrix.com> References: <1436975173.32371.121.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1436975173.32371.121.camel@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: Ian Campbell , xen-devel Cc: minios-devel@lists.xenproject.org, Ian Jackson , Roger Pau Monne , Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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