[Xen-devel] XCP: Allow XCP to use ocaml library bindings in Xen unstable (which will become Xen 4.1)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

The following series against xen-api-libs.hg, xen-api.hg and
xen-unstable.hg (to be posted as replies to this mail shortly) lays some
groundwork to allow XCP to be used against xen-unstable (and therefore
eventually the 4.1 release).

I have very much glossed over (i.e. hacked up the bare minimum of) the
actual toolstack port to xen-unstable, since my primary aim was simply
to do the groundwork to allow the use of the in-tree bindings in order
to ensure that Xen 4.1.0 is released with something with a baseline
level of usefulness to XCP. However I did do enough to allow
installation and starting of a PV guest and a successful "quicktest
-all" run (100% pass, FWIW).

I have arranged that the xen-api-libs.hg and xen-api.hg patches which
can be applied now without compromising the existing Xen 3.4 based XCP
platform are at the head of the relevant series and that the stuff which
depends on the transition to Xen 4.1 comes afterwards and have the
REBASE-4.1 prefix (followed by my hacks and other bits and pieces,
marked with HACK, they are just for reference and should be applied
to /dev/null only). The intention is that the xen-unstable bits can be
applied before Xen 4.1 in order that the infrastructure is in place when
XCP comes to rebase.

For my testing I have been using the build-xapi-toolstack.sh script from
http://xenbits.xen.org/xapi/install.html so in actual fact some of the
patches right at the start of the xen-api-libs.hg and xen-api.hg series
as well as the entire xen-dist-ocaml.hg series are actually fixes for
issues I encountered when using that script and doing RPM builds
outside /usr/src hopefully it is obvious what is what.

While doing this work I started to wonder if using the xb, xs, xc, xl
etc names at the toplevel of the ocaml module namespace was wise/polite?
I'm not sure what support ocaml has for module namepacing but perhaps we
should move the in-tree bindings to e.g. xen.lowlevel.{xb,xs,xc,xl} (to
arbitrarily pick up the convention used in the python bindings)?

I also wonder about maintaining non-Xen specific support libraries (such
as uuid, log and mmap) in the xen source tree. Perhaps these could be
pushed further down into the ocaml ecosystem and become prerequisites of
Xen? (assuming there is nothing similar already in the wider ocaml
world). Some of the modules have grown slightly different interfaces in
xen-api-libs.hg vs xen-unstable.hg, in some cases (e.g. uuid module)
resynchronising is simple, in others (e.g. log module) it is not so
trivial. This would be partially solved by namespacing the two sets of
modules I guess but that seems non-optimal in terms of number of module
to maintain.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel