Re: Integrating QOM into QAPI

[Marc-André Lureau]

Hi

On Wed, Jan 22, 2020 at 4:25 PM Markus Armbruster <address@hidden> wrote:
>
> Alex Bennée <address@hidden> writes:
>
> > Marc-André Lureau <address@hidden> writes:
> >> 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.
>
> I vaguely remember claims that GObject falls short of our needs.  Sadly,
> I don't remember the details.  This is why major features should come
> with a design document.
>
> https://wiki.qemu.org/Features/QOM ain't: it does not mention GObject.
> I'm afraid that page has fallen too far behind the code to be useful to
> anyone not familiar with the code.

>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

A possible initial approach is to have all the type system and object
allocation done by GObject under the hood (what I hacked), while
keeping all the properties handled by QOM. Then, figure out a
migration to GObject properties (which are also being refactored a bit
upstream). If there is enough interest, I will keep investigating. But
for now, helping with meson seems more urgent.

>
> >> 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?
>
> Comparing the composition tree complete with properties and property
> values before and after feels like a useful regression test.  Any
> takers?
>


-- 
Marc-André Lureau