From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: [Xen-API] [PATCH 2 of 4] xc: split xc non-upstream bindings into xcext module Date: Thu, 18 Nov 2010 14:36:20 +0000 Message-ID: <4CE539E4.9000204@eu.citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-api@lists.xensource.com Cc: xen-devel , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 18/11/10 10:50, Ian Campbell wrote: > # HG changeset patch > # User root@localhost.localdomain > # 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. -- Vincent