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: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl stubdom API cleanup
From: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Thu, 8 Jul 2010 18:18:23 +0100
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 08 Jul 2010 10:19:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1278598709.28432.589.camel@xxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5
On 08/07/10 15:18, Ian Campbell wrote:
On Thu, 2010-07-08 at 15:03 +0100, Stefano Stabellini wrote:
On Thu, 8 Jul 2010, Vincent Hanquez wrote:
On 07/07/10 17:53, Stefano Stabellini wrote:
I though we wanted to make stubdoms transparent to libxenlight users,
why do you want to expose them now?

   From the users yes, from the libxenlight users (aka developers) no.
It's also a good way to get the policy out of libxenlight. For example the
32mb value which might or might not change in future.

Fair enough.
I ack the whole series then.

Is it necessary to pull the mechanism out along with the policy though?

Necessary is quite a strong word.

Could the libxl user not specify one of nostubdom, stubdom or
libxlchooses (the default?) and let the internals of libxl take care of
actually starting it etc?

Starting a stubdom or not, imply 2 very different side effects (e.g. memory wise). Separating the API give better error reporting, more room for action (e.g. creating a domain without stubdom if you don't have those N mb to spare), and it also simplify the ocaml bindings not having to encode complex semantics on the ocaml side.

--
Vincent

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

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