[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries
(this is clearly not 4.6 material, aiming for 4.7) In <1431963008.4944.80.camel@xxxxxxxxxx> 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, 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... I've now completely removed the osdep layer. 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. The original proposal has morphed into docs/misc/toolstack-library-abis.pandoc here, and I've been trying to update in the patches which touch things, which is useful for book keeping as this work progresses. However I'm not sure it serves a useful long term purpose (certainly not with the level of detail of the per-library function names). I shall likely keep it around for a few iterations but I think eventually I'll strip it out or replace it with something more suitable for long term documentation. Ian _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |