Re: [PATCH 3/7] qemu: domain: Add XML namespace code for overriding device config
On Mon, Mar 21, 2022 at 15:34:46 +0000, Daniel P. Berrangé wrote:
On Mon, Mar 21, 2022 at 04:24:36PM +0100, Peter Krempa wrote:
> Implement the XML parser and formatter for overriding of device
> properties such as:
>
> <qemu:deviceOverride>
s/deviceOverride/devices/
> <qemu:device alias='ua-disk'>
> <qemu:property name='prop1' type='string'
value='propval1'/>
> <qemu:property name='prop2' type='signed'
value='-321'/>
> <qemu:property name='prop3' type='unsigned'
value='123'/>
> <qemu:property name='prop4' type='bool'
value='true'/>
> <qemu:property name='prop5' type='bool'
value='false'/>
> <qemu:property name='prop6' type='bool'
value='false'/>
> <qemu:property name='prop6' type='remove'/>
> </qemu:device>
> </qemu:deviceOverride>
This all applies to the frontend. Could we make this work
with the backend too ? Obviously there are many different
types of backend, so it is less convenient to implement
that, but would at least be nice to have a thought about
how we could represent it in the XML config.
Yes it can be easily ammended to work with certain backend types ...
namely netdev, object, and maybe at some point even chardev, as they
are/will be using JSON too. For others such as -fsdev we still have an
ad-hoc formatter so that won't work.
I'm not sure how easy it will be to wire up for -blockdev though, while
that uses JSON, it has nested types and also nested backends, so the
identification of which one to modify might be non-trivial.
Nested types can be theoretically handled by nesting the equivalent of
the 'property' tag such as:
<qemu:property name='prop1' type='child'>
<qemu:property name='overrideme' type='string'
value='blurb'/>
</qemu:property>
Some ideas:
1. Type specific backend at the top level
<qemu:device alias='ua-disk'>
<qemu:property name='prop1' type='string'
value='propval1'/>
<qemu:property name='prop2' type='signed'
value='-321'/>
</qemu:device>
<qemu:blockdev alias='ua-disk'>
<qemu:property name='prop1' type='string'
value='propval1'/>
<qemu:property name='prop2' type='signed'
value='-321'/>
</qemu:blockdev>
2. Type specific backend at the inner level
<qemu:device alias='ua-disk'>
<qemu:property name='prop1' type='string'
value='propval1'/>
<qemu:property name='prop2' type='signed'
value='-321'/>
<qemu:blockdev alias='ua-disk'>
<qemu:property name='prop1' type='string'
value='propval1'/>
<qemu:property name='prop2' type='signed'
value='-321'/>
</qemu:blockdev>
</qemu:device>
3. Inner generic backends/frontends:
<qemu:device alias='ua-disk'>
<qemu:frontend>
<qemu:property name='prop1' type='string'
value='propval1'/>
<qemu:property name='prop2' type='signed'
value='-321'/>
</qemu:frontend>
<qemu:backend>
<qemu:property name='prop1' type='string'
value='propval1'/>
<qemu:property name='prop2' type='signed'
value='-321'/>
</qemu:backend>
</qemu:device>
I think that for symmetry we should go with this. It will also be really
easy to adapt the current code to to it. It's a bit verbose for the user
though.
One other thing to consider is that on the top level we will probably
want to leave some room for things which are not under <devices> but
users may want to override such as CPUs, thus I'd leave the top level
for containers and not deal with backends at that level.