[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [Minios-devel] [PATCH v4 0/<VARIOUS>] Begin to disentangle libxenctrl and provide some stable libraries
In <1431963008.4944.80.camel@xxxxxxxxxx> I proposed stabilising some parts of the libxenctrl API/ABI by disaggregating into separate libraries. This is v5 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ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂv5 git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.gitÂÂÂÂÂÂÂÂÂÂÂÂÂv5 git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git v5 git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.gitÂÂÂÂÂÂÂÂÂÂÂÂÂÂv5 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: * xen.git now has a substantial number of acks * mini-os side is now completely acked * qemu-xen is little over half acked/reviewed, and the rest are updated based on feedback. * qemu-xen-traditional one patch acked 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/v5.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 v5-with-doc branch of the xen.git linked to above. I propose 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 I believe all the relevant/related patches are acked and this would make a (small) dent in the set of things to keep in the air. Ian. _______________________________________________ Minios-devel mailing list Minios-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel _______________________________________________ Minios-devel mailing list Minios-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |