| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [Xen-API] [PATCH 2 of 4] xc: split xc non-upstream b
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;
> 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.
Is this not suitable for upstreaming?
Gianni
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home