On Thu, Jan 15, 2026 at 03:00:23PM +0100, Gerd Hoffmann wrote:
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.
Ah, ok. Clearly I'm not an XML expert ;)
I like your second version more because it is at least closer to nvram and (hopefully) easier to remember.
Hopefully firmware autoselection will take care of picking the right values in 99% of scenarios and users won't have to worry about it at all. But I like the second version better myself, it's less verbose.
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 :)
So, just continue that scheme and pick what you personally prefer?
Right, but I don't necessarily want to spend the time reworking the series only to see the XML design rejected again afterwards, so I figured I'd try to get feedback ahead of time. Let's give it a couple more days. If I don't hear anything by next Monday, I'll assume other folks are okay with the options that the two of us like and implement it :) Thanks! -- Andrea Bolognani / Red Hat / Virtualization