On Mon, Jun 22, 2026 at 18:00:21 +0100, Daniel P. Berrangé wrote: > On Fri, Jun 19, 2026 at 12:28:12PM +0200, Peter Krempa via Devel wrote: > > From: Peter Krempa <[email protected]> > > > > Add general infrastructure for converting the generated introspection > > into XML which can be returned via 'virConnectGetIntrospection' and > > use it in the qemu driver. Example of the generated introspection XML: > > > > $ virsh introspection > > <libvirt-introspection> > > <hypervisor> > > <api name='virConnectBaselineCPU'> > > <flags dec='3' hex='0x3'/> > > </api> > > <api name='virConnectBaselineHypervisorCPU'> > > <flags dec='7' hex='0x7'/> > > </api> > > <api name='virConnectClose'/> > > This makes me somewhat uneasy. It is a pretty low level representation > of the C API, and so not so helpful for application developers in non-C > language.
Well yea. But this API is meant to represent the capabilities of the main API of the library which is C. Obviously it's XML so can easily be extended. We can add the RPC function names which are still 1:1 at this point including the arguments. That can still be usedful. > Most obviously, an application developer outside C will not know what > libvirt C API name they are using. A single API in Perl may map to A library-binding which wants to expose this can translate it to their jargon if they wish so. Basically expose their own schema which may or may not be built on this. And I'm fairly sure they will have harder time building the schema if they don't know what the daemon supports. > multiple APIs in C depending on parameters passed. While this shows that this API may not be useful for them it doesn't say that the API isn't useful per-se. > In Rust, we have considered an API design for flags that does not > express them as integer constants at all. The "builder pattern" > would have API names per flag instead: > > https://gitlab.com/libvirt/libvirt-rust/-/work_items/10 > > I don't think this XML schema really works nicely enough for non-C > usage. It's not really meant to. Non C usage ought to have their own schema. Difference in the language can't IMO be really expressed nicely. The schema may still be useful for the translation layer in the bindings. The bindigs in the end don't need to export this.
