[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
takers?
- Re: Making QEMU easier for management tools and applications, (continued)
- Re: Making QEMU easier for management tools and applications, Markus Armbruster, 2020/01/21
- Re: Making QEMU easier for management tools and applications, Stefan Hajnoczi, 2020/01/21
- Re: Making QEMU easier for management tools and applications, Marc-André Lureau, 2020/01/21
- Integrating QOM into QAPI (was: Making QEMU easier for management tools and applications), Markus Armbruster, 2020/01/21
- Re: Integrating QOM into QAPI (was: Making QEMU easier for management tools and applications), Daniel P . Berrangé, 2020/01/21
- Re: Integrating QOM into QAPI, Markus Armbruster, 2020/01/21
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/21
- Re: Integrating QOM into QAPI, Peter Maydell, 2020/01/21
- Getting whole-tree patches reviewed and merged (was: Integrating QOM into QAPI), Markus Armbruster, 2020/01/22
- Re: Integrating QOM into QAPI, Alex Bennée, 2020/01/22
- Re: Integrating QOM into QAPI,
Markus Armbruster <=
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/22
- Re: Integrating QOM into QAPI, Peter Maydell, 2020/01/22
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/22
- Re: Integrating QOM into QAPI, Markus Armbruster, 2020/01/23
- Re: Integrating QOM into QAPI, Paolo Bonzini, 2020/01/24
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/24
- Re: Integrating QOM into QAPI, Paolo Bonzini, 2020/01/25
- Re: Integrating QOM into QAPI, Peter Maydell, 2020/01/25
- Re: Integrating QOM into QAPI, Christophe de Dinechin, 2020/01/26
- Re: Integrating QOM into QAPI, Marc-André Lureau, 2020/01/26