From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: [PATCH 0/3] libxl stubdom API cleanup Date: Fri, 09 Jul 2010 12:05:30 +0100 Message-ID: <4C37027A.5030207@eu.citrix.com> References: <1278507656-7745-1-git-send-email-vincent.hanquez@eu.citrix.com> <4C35B3E1.2010106@eu.citrix.com> <1278598709.28432.589.camel@zakaz.uk.xensource.com> <20100709081755.GC31695@whitby.uk.xensource.com> <4C36FD7A.1070303@eu.citrix.com> <20100709105101.GD31695@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100709105101.GD31695@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: Ian Campbell , Xen Devel , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 09/07/10 11:51, 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). > I think that either is fine from my point of view; as long as I don't have to capture two very different semantics (starting a program | starting a domain) in one call. -- Vincent