[libvirt] [PATCH v4 1/3] conf: Extend <loader/> and introduce <nvram/>
Daniel P. Berrange
berrange at redhat.com
Fri Aug 22 16:57:57 UTC 2014
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 :|
More information about the libvir-list
mailing list