Re: [Xen-devel] [PATCH 17 of 19] tools: libxl: hide selection of device-model, hvmloader and BIOS by default

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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
variable.

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.

Ian.


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