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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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

The upstream xen-unstable.hg bits have been applied as of
22663:4e120cb427f4. Therefore I have dropped xen-devel this time around.

The main difference in this version is that based on the feedback I have
dropped the xc/xcext split. Instead I agree that it makes more sense to
simply include the required interfaces into the XCP hypervisor patch
queue. This will make it easier to upstream stuff without needing to go
back and s/xcext/xc/. It also allows the library additions + bindings to
be merged into the hypervisor patch which adds the hypercalls which
seems sensible.

The following new series against "xen-4.1.pq.hg" (which is actually
against xen-unstable.hg 22694:9b5d121c8805) includes PoC versions of
these patches with the code being taken directly from xen-api-libs.hg/xc
and massaged into the upstream code base.

The patches tagged XCP.PQ were pulled out of the existing XCP patch
queue as a basis for the others.

I have indicated in the checkin comments if I think a patch should be
folded into an existing patch in the queue.

I didn't put much (if any) thought into if/how/when these additions
should be upstreamed. Some of them look like they belong more in libxl
or could be hoisted into pure ocaml with the addition of some constants
to the bindings.

Ian.

On Tue, 2010-12-07 at 14:30 +0000, Ian Campbell wrote:
> 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@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api