[libvirt] [PATCH v2 00/16] domcaps: use virTristateBool

Cole Robinson crobinso at redhat.com
Wed Mar 13 14:38:19 UTC 2019


On 3/6/19 6:36 PM, Cole Robinson wrote:
> v1 posting: https://www.redhat.com/archives/libvir-list/2019-February/msg01088.html
> 
> v2 changes:
>      - Rebase to master
>      - Remove the full.xml test in patch #3
>      - Add virCapsEnum 'format' and use it
>      - Extend docs to explain optional XML
> 
> v1 cover letter:
> Extending domaincapabilities with new XML schema is currently a bit of
> a maintenance pain. Consider the case of adding a new enum for listing
> <sound> models. I want to output this info for the qemu driver.
> 
> Internally in the domaincapabilities plumbing, whether a <device> is
> supported= is tracked with boolean true/false. If I extend that
> pattern for <sound> devices and fill in data for the qemu driver, the
> other domcaps implementations will now automatically output a new XML
> element:
> 
>    <sound supported='no'>
> 
> Now, for bhyve I can 'git grep' confirm that it doesn't have any
> <sound> support, but for xen/libxl it _is_ supported. So if I don't
> fill in accurate support in the xen driver, I've just made their
> domcaps report blatantly incorrect info.
> 
> Ideally I would make these <sound> changes and the other drivers output
> would _not_ change. xen output would now be incomplete, but not
> obviously wrong, which is easier on me the developer, and safer for the
> API consumer.
> 
> This moves domcaps plumbing in that direction. It switches most
> internal 'supported' fields to virTristateBool so we can track an
> ABSENT state and map that to outputting no XML. Explicit supported='no'
> values are filled in where needed to ensure existing driver XML doesn't
> change. cpu and sev supported= values are left unconverted, but they
> require semi-special handling anyways so aren't really affected by the
> problem I laid out above.
> 
> 
> In v2, I additionally added a mechanism to make <enum> values optionally
> formatted. Right now whenever a new <enum> is added, if the parent bit
> is supported (like <disk supported='yes'/>), the new <enum> is
> automatically formatted as well. This has the same problem described
> above with the @supported bit. Now drivers are required to set a
> virCapsPtr.report = true if they want the <enum> to be formatted.
> Existing drives have this value filled in to maintain back compat.
> 
> Again, bhyve changes are untested. If someone can give them a spin
> that would be appreciated, otherwise I will try to get a freebsd build
> setup.
> 

I have confirmed that after applying this series:

* bhyve builds and tests pass on freebsd 12.0
* runtime libxl domaincapabilities output on f29 does not change for 
both xenpv and xenfv

- Cole




More information about the libvir-list mailing list