[libvirt] [PATCH v4 1/3] conf: Extend <loader/> and introduce <nvram/>

[Eric Blake]

On 08/22/2014 10:43 AM, Daniel P. Berrange wrote:

>>>    <os>
>>>      <type>hvm</type>
>>> -    <loader>/usr/lib/xen/boot/hvmloader</loader>
>>> +    <loader readonly='on' type='rom'>/usr/lib/xen/boot/hvmloader</loader>
>>
>> readonly='yes' is a bit more typical of other XML constructs.
>>
>>> +    <nvram>/var/lib/libvirt/nvram/guest_VARS.fd</nvram>
>>
>> You chose <nvram> to be a sibling, rather than a child, of <loader>.  Is
>> it legal to have <nvram> in isolation, or can it only appear when
>> <loader> is present?  If the former, then you are okay; if the latter,
>> then I'd rather see it as a child than a sibling.
> 
> <loader> is a long standing element whose contents is a string path.
> So from a back compatibility POV we can't make <nvram> be a child
> of that, even though it would make sense.

Hmm.  But what if we allow a choice between:

<loader type='rom'>/path/to/rom</loader>

and

<loader type='pflash'>
  <config>/path/to/config</config>
  <nvram>/path/to/nvram</nvram>
</loader>

that is, use the (optional) type='rom|pflash' for gating whether the
rest of the <loader> element is a single name (old style) or structured
layout (new style)?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140822/ae78ad82/attachment-0001.sig>