On Thu, Jan 15, 2026 at 03:19:17AM -0800, Andrea Bolognani wrote: > On Thu, Jan 15, 2026 at 11:32:48AM +0100, Gerd Hoffmann wrote: > > > > If we want to introduce a new element, perhaps it could look like > > > > this: > > > > > > > > <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader> > > > > <varstore type='uefi-vars'> > > > > <template path='/usr/share/edk2/ovmf/OVMF_VARS.qemuvars.json'/> > > > > <source path='/path/to/guest.json'/> > > > > </varstore> > > > > > <loader type='rom'>/usr/share/edk2/ovmf/OVMF.qemuvars.fd</loader> > > > <varstore template='/usr/share/edk2/ovmf/OVMF_VARS.qemuvars.json' > > > path='/path/to/guest.json'/> > > > > <varstore template='...'>/path/to/guest.json</varstore> ? > > > > Following what we are doing for nvram ... > > That would rule out extending with sub-elements later: > > <varstore template='...'> > /path/to/guest.json > <db>...</db> > </varstore> > > is not valid XML. > > > That said I have no idea what guidance is typically used by libvirt when > > adding stuff to the schema, specifically the choice between attributes > > and sub-elements looks a bit random to me ... > > There's no hard and fast rule so often it's down to the taste of > whoever introduces the new element/attribute. Having to go through > review normalizes this to some extent, but ultimately what we have > today is just the result of a schema growing organically over 20 > years while maintaining full backwards compatibility :)
In the case of <loader> that was a design mistake we made very very early in libvirt development before we appreciated the downsides it has for future extension. These days we try to avoid doing that in general. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
