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


Re: [Xen-devel] [PATCH 17 of 19] tools: libxl: hide selection of device-

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 17 of 19] tools: libxl: hide selection of device-model, hvmloader and BIOS by default
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 15 Apr 2011 08:53:41 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 15 Apr 2011 00:54:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19879.14455.868160.586567@xxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <patchbomb.1302607739@xxxxxxxxxxxxxxxxxxxxx> <20dcc3b31fd416636a69.1302607756@xxxxxxxxxxxxxxxxxxxxx> <19879.14455.868160.586567@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-04-14 at 19:09 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 17 of 19] tools: libxl: hide 
> selection of device-model, hvmloader and BIOS by default"):
> > At the libxl API level:
> ...
> >       * Add libxl_device_model_info.device_model_version allowing the
> >         user to say which qemu version (e.g. old qemu-xen or qemu
> >         upstream) they want for a domain.
> Perhaps this ought to be a series of #defines, rather than an
> integer ?  Integers have the virtue of sortability but it's not clear
> that that's important; a series of #defines and corresponding strings
> would be easier in the config file I think.

I agree but I had trouble figuring out what the strings/#define names
should be. The current libxl code uses "old" and "new" which clearly
falls apart if we need to support e.g. a new upstream command line
syntax. I didn't like the "qemu-dm" vs. "upstream" distinction either.

So I'm open to suggestions...

(also, enum not #define, I think, maybe a #define for the default)

> > -        if (strstr(dm_info->device_model, "stubdom-dm"))
> > +        if (strstr(libxl__domain_device_model(&gc, dm_info), "stubdom-dm"))
> >              *need_memkb += 32 * 1024;
> Surely this strstr(,"stubdom-dm",) can be got rid of too, in favour of
> "stubdom=1" or something ?

I don't want to expose the choice of stub or non-stub too directly so I
think it would be better as a blahblah_override in the cfg file.

I'm undecided if this should be part of the set of values associated
with device_model_version or if it is orthogonal enough to be a separate

At the moment the only way the "stubdom-dm" string can arise is if the
user used the device_model_override, since we are changing the field
name anyway I guess we could also give a further warning if the device
model given is "stubdom-dm" and point to the new syntax.


Xen-devel mailing list

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