This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Xen-API] [PATCH 2 of 4] xc: split xc non-upstream b

To: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-API] [PATCH 2 of 4] xc: split xc non-upstream bindings into xcext module
From: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Date: Fri, 19 Nov 2010 13:42:41 +0000
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 19 Nov 2010 05:44:18 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CE539E4.9000204@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1290077414@xxxxxxxxxxxxxxxxxxxxxx> <be3de1c0aa0687ef9fa6.1290077416@xxxxxxxxxxxxxxxxxxxxxx> <4CE539E4.9000204@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>