[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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

>>>    &lt;os&gt;
>>>      &lt;type&gt;hvm&lt;/type&gt;
>>> -    &lt;loader&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt;
>>> +    &lt;loader readonly='on' type='rom'&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt;
>>
>> readonly='yes' is a bit more typical of other XML constructs.
>>
>>> +    &lt;nvram&gt;/var/lib/libvirt/nvram/guest_VARS.fd&lt;/nvram&gt;
>>
>> 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

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]