Re: [PATCH v2 00/21] qom: introduce property flags to track external user input

[Kevin Wolf <kwolf@redhat.com>]

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