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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list