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] libxl: Support linux-stubdom in libxl

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] libxl: Support linux-stubdom in libxl
From: ZhouPeng <zpengxen@xxxxxxxxx>
Date: Mon, 6 Jun 2011 19:56:52 +0800
Cc: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jiageng Yu <yujiageng734@xxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 06 Jun 2011 05:06:40 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dDsbPdTktkOgWmQpQVrqR1hXCecaC1loEgFiNtevexI=; b=F5rlk8T8beOPgV9oBCzdSZXLenCEtRDEFdLWdmmLa5AW9JUoKiLGPzghVaRTBfR8ST UjWo9cpLBy61V6vbpWwa+NCiQ8tPuguagwjAi43+pWKhVTB74DFkdp5vC/oa5coOY1w8 E3vA0qryYyn8XClaZ6PCGO/doBcNJn29HFuWg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i33irkfYr9ge0POFwezKg09hEoO79H13zgluhes+giK2AIFTgWjp6CUPjckcoHxA0+ tr+tzBqIecD3XDmgmKpznIp7KYURsMBltCq+UwMzECpBB6ONtJgTjyjQLAozMFZaA+rd KBGAIOKHqhkheNIx435bIJfFNA/XfwE4bwi+g=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1307025357.775.277.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: <BANLkTikCb2GEodgNCDyL9_qgfLE42hc+pA@xxxxxxxxxxxxxx> <1306933116.775.237.camel@xxxxxxxxxxxxxxxxxxxxxx> <BANLkTikNRNzgPo9nZ7i8Fgf3FVQ6zTZt_w@xxxxxxxxxxxxxx> <1307024747.775.275.camel@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1106021530270.12963@kaball-desktop> <1307025357.775.277.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I think class is better than mode?
'Mode' is somewhat misleading to new newbie?
It seem be telling there is one device model instance, which has
mutiple working mode.
Just like kernel mode or user mode to describe one OS‘s current working mode.


1) device_model_class
2) device_model_deployment
3) device_model_instance
4) device_model_mode
If I have one vote for all the above chances, I will select '...class' :)

And I suggest one :
device_modele_mechanism
:)


2011/6/2 Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>:
> On Thu, 2011-06-02 at 15:31 +0100, Stefano Stabellini wrote:
>> On Thu, 2 Jun 2011, Ian Campbell wrote:
>> > On Thu, 2011-06-02 at 14:40 +0100, Jiageng Yu wrote:
>> > > diff -r 37c77bacb52a tools/libxl/libxl.idl
>> > > --- a/tools/libxl/libxl.idl    Mon May 23 17:38:28 2011 +0100
>> > > +++ b/tools/libxl/libxl.idl    Wed Jun 01 03:24:57 2011 +0100
>> > > @@ -196,6 +196,7 @@
>> > >      ("dom_name",         string),
>> > >      ("device_model_version", libxl_device_model_version),
>> > >      ("device_model_stubdomain", bool),
>> > > +   ("device_model_linux_stubdomain", bool),
>> > >      ("device_model",     string, False, "if you set this you must set 
>> > > device_model_version too"),
>> > >      ("saved_state",      string),
>> > >      ("type",             libxl_domain_type),
>> >
>> > I think what we actually want here is a single device_model_type
>> > Enumeration, values are something like "process", "stub-linux",
>> > "stub-minios", rather than multiple device_model_XXX_stubdom booleans.
>>
>> indeed
>>
>>
>> > I'm not convinced device_model_type is a good name, hopefully someone
>> > can suggest something better. (device_model_mode??)
>>
>> some suggestions:
>>
>> 1) device_model_class
>> 2) device_model_deployment
>> 3) device_model_instance
>>
>> I vote for 3)
>
> I don't think deployment or instance has the right meaning here. class
> is better but still doesn't feel right.
>
> maybe ..._mode?
>
> </bikeshed>
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>



-- 
Zhou Peng
Operating System Technology Group
Institute of Software, the Chinese Academy of Sciences (ISCAS)

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