[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Integrating QOM into QAPI

From: Markus Armbruster
Subject: Re: Integrating QOM into QAPI
Date: Wed, 22 Jan 2020 13:24:52 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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.

>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]