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

[Daniel P. Berrange]

On Fri, Aug 22, 2014 at 10:51:18AM -0600, Eric Blake wrote:
> 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)?

That is still going to cause existing apps which are parsing the XML
to fail due to the change in child content. Changing content from a
text node to elements is something I don't think we can do with the
XML schemas.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|