WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/3] libxl stubdom API cleanup

To: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl stubdom API cleanup
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 9 Jul 2010 11:59:23 +0100
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Vincent Hanquez <Vincent.Hanquez@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 09 Jul 2010 04:07:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100709105101.GD31695@xxxxxxxxxxxxxxxxxxxxxxx>
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: <1278507656-7745-1-git-send-email-vincent.hanquez@xxxxxxxxxxxxx> <alpine.DEB.2.00.1007071752210.21432@kaball-desktop> <4C35B3E1.2010106@xxxxxxxxxxxxx> <alpine.DEB.2.00.1007081455060.21432@kaball-desktop> <1278598709.28432.589.camel@xxxxxxxxxxxxxxxxxxxxxx> <20100709081755.GC31695@xxxxxxxxxxxxxxxxxxxxxxx> <4C36FD7A.1070303@xxxxxxxxxxxxx> <20100709105101.GD31695@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Fri, 9 Jul 2010, Tim Deegan wrote:
> At 11:44 +0100 on 09 Jul (1278675850), Vincent Hanquez wrote:
> > On 09/07/10 09:17, Tim Deegan wrote:
> > >> Is it necessary to pull the mechanism out along with the policy though?
> > >>      
> > > Or, if we're taking some mechanism out, couldn't we take _all_ the
> > > mechanism out?
> > 
> > Which one do you have in minds ?
> 
> It looks like your patch leaves some "create a stubdom" functions in the
> libxl API.  I'd have thought libxl should either handle stubdoms
> entirely or not at all.  (Unless stubdom creation needs some low-level
> grunge that will uglify the libxl API if it's exposed that far up - I
> can't think of any except PRIV_FOR though).
> 
> > > The idea of a stub domain doesn't seem like one that
> > > libxl necessarily needs to know about.
> > >    
> > yes, indeed. the stubdom create could move as a xl helper.
> > On the ocaml side reimplementing stubdom create is a trivial composition 
> > of smaller libxl function (create/build/add devs) which are already bound.
> 
> That sounds cleaner to me.
> 

I am not so sure about this: a stubdom is not just a normal PV guest, it
also needs some special plumbings in xenstore.
By design libxl clients are not required to know about xenstore,
therefore we cannot have stubdoms entirely built by libxl clients.
I think that working around this would be worse than Vincent's current
patch series.


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