Am 16.03.2026 um 16:43 hat Markus Armbruster geschrieben:
Daniel P. Berrangé <berrange@redhat.com> writes:
For -object / object_add we introduced formal QAPI modelling of all Object subclasses which implement the UserCreatable interface. IIUC, that gives us the desired separation between internal and external views, as only properties declared in qapi/qom.json are publically settable.
Correct. Kevin Wolf's work.
This work did not apply to the Device classes because the historical baggage with qdev being grafted onto qom, means we don't have that working via the UserCreatable inteface or -object/object_add.
Can we bring Device into the same world though ?
Kevin Wolf took a stab at it. I had a hard time understanding it back then. Various pennies finally dropped when he patiently explained it to me in person. I disliked certain aspects of its design, and wanted to explore a bit more. Never found the time. Perhaps we should just take it despite my design misgivings.
Adding 1000 device types to QAPI is a huge job, so it would need to be a long incremental job, unless perhaps we auto-generate QAPI descriptions for everything that already exists ?
Doing things incrementally was my idea when I did the patch series to prepare it (which really only completed the converstion for -object, getting rid of some of the duplication between QOM and QAPI definitions that we currently have - but the same things would probably also be the prerequisite for starting to convert devices). Even if you could automate the conversion, doing thousands of devices with different maintainers in a single series seems completely unmanageable.
Interesting idea.
QAPI is declarative: types and their properties are declared in a schema.
QOM is imperative: we execute C code to create types and their properties.
Extracting a QAPI schema from the C code is impossible in the completely general case (halting problem), and merely impractical (I believe) in the special cases we have.
We could start with QOM introspection instead: qom-list-types and qom-list-properties. These are only mostly complete, but should be good enough.
Mapping QOM types to QAPI types would involve guesswork, because QOM doesn't have a type system, it has strings and bailing wire.
QOM itself is typed, only the QemuOpts it normally takes as input isn't. You just have to find the right visitor call in the code and then you can pretty much copy the type into the QAPI schema (sometimes it's more complex than that because visitor calls are made conditionally or in a loop or whatever, but it's not guesswork anyway).
Schema documentation would be placeholders at best. We could try to extract documentation from -device T,help. Most properties have nothing there, and the remainder likely needs to be rewritten completely to be fit for purpose.
FWIW, writing documentation was the real work in converting -object. Automating everything else can possibly be a minor convenience improvement, but in comparison to documenting stuff it's trivial enough anyway.
More generally anything we can do to bring qdev & qom closer together feels desirable. I dream of a future where -device/device_add are obsolete....
That would be lovely.
If you decide to finally stop blocking it, let me know. Maybe I can find some time to resurrect something, though having to rebase after four(?) years doesn't sound like fun. Kevin