[Xen-devel] Re: [Xen-API] [PATCH 2 of 4] xc: split xc non-upstream bindings into xcext module

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Thu, 2010-11-18 at 14:36 +0000, Vincent Hanquez wrote:
> On 18/11/10 10:50, Ian Campbell wrote:
> > # HG changeset patch
> > # User root@xxxxxxxxxxxxxxxxxxxxx
> > # Date 1290004595 18000
> > # Node ID be3de1c0aa0687ef9fa6ad2ac5cfa1a74fb14484
> > # Parent  cdd93d37eb6036e9901ecc0cd1f949901ff1aea4
> > xc: split xc non-upstream bindings into xcext module.
> >
> > move anything which is not provided by upstream libxc and the
> > associated ocaml bindings in a separate xcext library to ease
> > replacement of xc library by upstream version.
> >
> > Some of this functionality could potentially be upstreamed straight
> > away but other bits rely on stuff from the XCP hypervisor patch queue.
> >
> > One change of not is that Xcext.hvm_check_pvdriver expects that domid is 
> > always
> > an HVM domain. This matches the existing callsites (and the name) and 
> > reduces
> > cross talk between xc and xcext.
> >    
> 
> This is breaking xiu. as i said before the xc C library in XCP is 
> different than the one in opensource;

That would be fine (or at least I'd have no grounds to complain ;-)) for
out-of-tree bindings but I don't think it is acceptable for in tree
bindings to duplicate infrastructure libraries in this way.

> There's an injection layer that give the ability to catch stuff and 
> redirect them to userspace, where
> we can simulate lots of things. Last time i checked this was still used 
> by a bunch of people for testing.

Absolutely, I think the XIU stuff is really very useful indeed. I think
it even has the potential for wider usefulness than just XCP.

Addressing this is next on my list so my plan is only half baked (if
that!) but I think the hooks necessary to support an injection
infrastructure of this type could be integrated into libxc without too
much pain. Doing this would allow xl, libvirt etc to also use the XIU
functionality for testing which I think would be really cool.

I've several possible approaches in mind:

      * Just whack the hooks and injection layer into libxc itself,
        there aren't really that many hook points or that much code in
        the injection layer...
      * Turn xc_injection_lib.c into a LD_PRELOAD'able library. Requires
        moving various, do_{domctl,ioctl,etc} stuff out of line in the
        library -- which I think is a good idea anyway.
      * Add functionality to libxc to allow it to dlopen a backend (e.g.
        pointed to by an envvar) containing the hook implementation with
        explicit calls to the layer as necessary.

Probably the second two are pretty much equivalent modulo the name of
the environment variable being either LD_PRELOAD or something else.

Initially I think I prefer the dynamic loading approaches to dropping
the injection stuff directly into libxc. In particular the dynamic
options allow the injection layer and XIU backend to live together
whereas the first option effectively has the injection layer in
xen-unstable.hg and the XIU backend possibly somewhere else which
doesn't seem helpful.

The dynamic solution also allows for other injection layers and backends
but I'm not sure how useful that actually is. Perhaps a valgrind
friendly backend or something like that, dunno.

Ian.


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