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

[Ian Campbell <Ian.Campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>]

A second version of each of these patch queues will follow shortly.

The major change is to make use of the proposed hooks in upstream
libxenctrl to reenable the XIU functionality. This allows xenstored and
xapi to run in an SDK VM. This depends on my "libxc: dom0 OS integration
cleanup+abstraction." series against xen-unstable.hg sent to xen-devel
last week.

I've not had any feedback on the module namespace issue so I haven't
done anything about that.

Ian.

On Thu, 2010-11-18 at 10:49 +0000, Ian Campbell wrote: 
> 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-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
> http://lists.xensource.com/xen-devel