Re: Integrating QOM into QAPI

["Alex Bennée" <alex.bennee@linaro.org>]

Marc-André Lureau <marcandre.lureau@gmail.com> writes:

> Hi
>
> On Tue, Jan 21, 2020 at 7:01 PM Markus Armbruster <armbru@redhat.com> wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> > On Tue, Jan 21, 2020 at 02:36:17PM +0100, Markus Armbruster wrote:
<snip>
>> >>     static const TypeInfo char_type_info = {
>> >>         .name = TYPE_FOO,
>> >>         .parent = TYPE_OBJECT,
>> >>         .instance_size = sizeof(Foo),
>> >>         .instance_init = ...,                   // methods to initialize
>> >>         .instance_post_init = ...,              // and finalize instances,
>> >>         .instance_finalize = ...,               // all optional
>> >>         .abstract = ...,                        // true or false (d'oh)
>> >>         .class_size = sizeof(FooClass),
>> >>         .class_init = ...,                      // methods to initialize
>> >>         .class_base_init = ...,                 // classes, optional
>> >>         .class_data = ...,                      // extra argument for them
>> >>         .interfaces = ...
>> >>     };
>> >>
>> >> There's substantial boilerplate, with plenty of hand-written code in the
>> >> gaps.  What of the boilerplate do we plan to generate?  How do we plan
>> >> to fill the gaps, if any?
>> >
>> > FWIW, even without a QOM generator, we can do waaaaaaay better on the
>> > amount of boilerplate needed for QOM without very much work. It just
>> > needs a few convenience macros writing.
>> >
>> > QOM is not GObject, but is heavily inspired by it and so looking at
>> > GObject gives us a design pattern we can aim to match in terms of
>> > amount of boilerplate.
>> >
>> > What we do manually with TypeInfo struct there has essentially always
>> > been done by a 1 line macro in GObject:
>> >
>> >   G_DEFINE_TYPE(virIdentity, vir_identity, G_TYPE_OBJECT)
>> >
>> > If implementing interfaces, there's 1 extra line needed per interface
>> > to associate them.
>> >
>> >   https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-DEFINE-TYPE:CAPS
>> >
>> >
>> > And what we do in the header file to add the 4 or more FOO_XXX macros,
>> > and the class struct and the object struct has recently been turned
>> > into a 2-liner:
>> >
>> >   #define VIR_TYPE_IDENTITY vir_identity_get_type()
>> >   G_DECLARE_FINAL_TYPE(virIdentity, vir_identity, VIR, IDENTITY, GObject);
>> >
>> >   https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-DECLARE-FINAL-TYPE:CAPS
>> >
>> > Or
>> >
>> >   #define VIR_TYPE_IDENTITY vir_identity_get_type()
>> >   G_DECLARE_DERIVABLE_TYPE(virIdentity, vir_identity, VIR, IDENTITY, GObject);
>> >
>> >   https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#G-DECLARE-DERIVABLE-TYPE:CAPS
>> >
>> >
>> > It would be nice to have a QOM code generator so that we can statically
>> > declare properties & parent/child/interface relationships, but for an
>> > immediate low cost win, better macros would be very useful IMHO.
>>
>> Volunteers?
>>
>
> Actually, we are not that far off from being able to use GObject
> altogether (I hacked something like that to play with), but I
> disgress...

As a mostly hands off observer who mainly c&p's QOM code when he has to
I have to ask is this a long term plan?

I've always found having our own hand rolled object system a little
incongruous given we lean heavily on the rest of glib.

> So introducing GObject-like macros? sure!
>
> There are plenty of refactoring to do. The problem when touching the
> whole code-base, imho, is review time. It may take a couple of
> hours/days to come up with a cocci/spatch, and make various patches
> here and there. But it takes often weeks and a lot of constant push to
> various folks to get all the reviews (as seens by the qdev prop-ptr
> series earlier for example). How can we better address whole code-base
> changes?

The problem with review time - especially for QOM - is having domain
knowledge to understand what is happening.

Are we happy that the existing qdev/qmp tests sufficiently exercise
QEMU's object model? Perhaps with a little extra tweaking of the tests
we could dump the object hierarchy and then compare it to the hierarchy
presented after modification. That might make it easier to have
confidence that these large scale but mostly mechanical changes don't
change anything externally visible?

--
Alex Bennée