Re: Integrating QOM into QAPI

[Paolo Bonzini <pbonzini@redhat.com>]

On 25/01/20 05:44, Marc-André Lureau wrote:
>     On 22/01/20 13:42, Marc-André Lureau wrote:
>     > From the top of my mind, this is the pain point when trying to use
>     GObject:
>     > - static/inlined object, not supported by GObject, unlikely to ever be
>     > - few users in qemu, transition possible.
>     > - 64k limit of GObject, for some reason, unlikely to change but I will
>     > take a look. Some users in qemu, code adaptation possible.
>     > - dynamic properties, possible in GObject with hacks, but not
>     > recommended and going to be deprecated from what I remember
>     > - "array" properties - would need extra layer/tweaks for compatibility
>     > - link properties - would need special handling
>     > - different limitations for type names and properties names
> 
>     The properties in general are very different between QOM and QAPI.  They
>     have different limitations and features as Marc-André mentioned, but an
>     especially important one is the integration with QAPI visitors.  This is
>     what allows us to support -object and object-add with the same code, and
>     is what separates QOM from GObject the most.
> 
>     Maybe it would be possible to build an adapter, but having written in
>     the past code that uses GType to do marshalling and unmarshalling, I'm
>     not really fond of repeating the experience...
> 
> I agree it is one of the things that look very different from gobject.
> At the same time, I think defining conventions/types or interface to
> describe hierarchy isn't so difficult, and then adapting the visitors
> shouldn't be either.

Note that there are a few "structured" properties that export a QAPI
struct rather than a scalar.  Those would be a bit more complex.  Links
might also be tricky.

Another small difference that came to mind is the different object
liveness model; GObject is mostly plain old reference counting (plus the
"floating reference" idea), while in QOM reference counting is secondary
and lifetime is mostly dictated by the object tree and "unparenting".
This is more of a conceptual difference; it could be easily retrofitted
in GObject.

> I try to find a good reason qom was chosen over gobject, and I can't
> find it.

The main reasons were integration with QAPI, and the object tree.
Though everything I say here is a kind of reverse engineering of
Anthony's brain because there aren't really any design documents besides
what's in include/qom/object.h (and he overlooked some aspects, for
example "unparent" was introduced a few months later).

Overall I don't think there would be much benefit in reusing GObject.
It's about 3k lines of code, quite a few would stay (those implementing
the tree) and a bunch more would have to be rewritten.  I don't think
we'd have any use for most of the features that QOM lacks, such as
signals.  Also, QOM is quite well documented and we should include its
documentation in docs/devel instead.

That said, coccinell-ing efforts on QOM code are definitely a good idea
since it's quite mature now and we know better what we need.  And there
are practical advantages too, it's not just code cleanups---see how your
series shows the default value of the properties in -device foo,help.

Paolo