[libvirt] [PATCH 00/10] domcaps: use virTristateBool

[John Ferlan]

On 2/19/19 3:09 PM, Cole Robinson wrote:
> 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.
> 
> Cole Robinson (10):
>   tests: domcaps: Add a default 'empty' test
>   tests: domcaps: Remove unused typedef
>   tests: domcaps: Remove 'full' test
>   conf: domcaps: Add single line formatting macro
>   conf: domcaps: use virTristateBool for 'supported'
>   qemu: domcaps: fill in explicit supported BOOL_NO
>   libxl: domcaps: fill in explicit supported BOOL_NO
>   bhyve: domcaps: fill in explicit supported BOOL_NO
>   schemas: domcaps: Make more elements optional
>   conf: domcaps: Don't output XML on tristate ABSENT
> 
>  docs/schemas/domaincaps.rng          | 20 +++++--
>  src/bhyve/bhyve_capabilities.c       | 20 +++++--
>  src/conf/domain_capabilities.c       | 26 ++++++----
>  src/conf/domain_capabilities.h       | 20 +++----
>  src/libxl/libxl_capabilities.c       | 18 ++++---
>  src/qemu/qemu_capabilities.c         | 26 ++++++----
>  tests/domaincapsschemadata/empty.xml | 16 ++++++
>  tests/domaincapstest.c               | 78 ++--------------------------
>  8 files changed, 103 insertions(+), 121 deletions(-)
>  create mode 100644 tests/domaincapsschemadata/empty.xml
> 

I think in patch3, you probably should remove the full.xml file too.

Logically, it seems things work; however, I am curious what happens
if/when this is applied to bhvye and libxl environments. I think it
would be good to get someone to apply this there and be sure there's no
unexpected (for you) failures.

Interesting "view" for <cpu> on "empty.xml" - digging deeper shows that
"mode" could be optional (at least that's how I read the formatdomain
text). So rather than "no" for all 3, there would be nothing.

Similarly for SEV the "no" just is some default/optional value matching
your RNG changes.  Also, even though it wouldn't necessarily be a
"feature" of perhaps Intel, someone running on AMD could I assume get a
different result than you got. IOW: Same problem I ran into with that 2
patch series trying to "fake" SEV output.

If cpu, devices, and features have no subelements - should they even be
displayed?  Leaving purely just the path, domain, machine, and arch output?

Even with all that - is there any thought that perhaps some application
has made use of the existing "functionality" to spit out "no" for those
undefined/missing (e.g. ABSENT) values.  IOW: It seems via the RNG we
would have made claims that certain output exists that we're now making
optional. I conceptually don't have an issue with it, I'm just thinking
terms of what API output contract we may have made.  Yes, those
applications should be able to handle missing fields, but at the very
least we probably would need to update the news.xml to let the consumer
know.

John