Re: [Xen-devel] [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info.

[Eric Shelton <eshelton@xxxxxxxxx>]

On Mon, Feb 9, 2015 at 4:11 AM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> On Tue, 2015-02-03 at 23:06 -0500, Eric Shelton wrote:
>> This enum gives the ability to select between a MiniOS-based QEMU
>> traditional stub domain and a Linux-based QEMU upstream stub domain.  To
>> use the Linux-based stubdomain, the following two lines should be
>> included in the appropriate xl.cfg file:
>>
>> device_model_version="qemu-xen"
>> device_model_stubdomain_override=1
>>
>> To use the MiniOS-based stubdomain, the following is used instead:
>>
>> device_model_version="qemu-xen-traditional"
>> device_model_stubdomain_override=1
>
> This doesn't seem to use this new stubdom_version option and I'm not
> really sure what it is for.
>
> Perhaps you meant this new thing to be a libxl internal Enum, rather
> than exposed to the application which is using libxl?

I believe Anthony's first patchset made this an explicit option for
xl.cfg (e.g., 'stubdom_version="linux"'), and then the second patchset
continued to use it internally, with the combination of
device_model_stubdomain_override and device_model_version setting its
value.  I suppose the main benefit of this approach is if we foresee
more than one stubdom flavor for QEMU-upstream, but we're nowhere near
that.

> I'm not sure wy
> the user would need to be given the choice -- it should be inherent in
> the device-model version and stubdom boolean selection.

In effect, that is how it works - as illustrated by the two xl.cfg
examples above.

Perhaps it is best to just eliminate the internal enum, and have the
code just look to device_model_version.  It has not been a good sign
that both Stephano (at least initially) and you have negatively
reacted to how it is currently being done.

- Eric

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel