[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: Thu, 23 Jan 2020 08:37:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Marc-André Lureau <address@hidden> writes:

> 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


Okay for us as long as the pointer chasing stays off the hot paths.  But
that's not obvious.

> - few users in qemu, transition possible.

Peter challenged this idea.

> - 64k limit of GObject, for some reason, unlikely to change but I will
> take a look. Some users in qemu, code adaptation possible.

Also lame.  I figure code adaption will involve pointer chasing.  Again,
beware of hot paths.  This one feels less likely to be a problem,

> - dynamic properties, possible in GObject with hacks, but not
> recommended and going to be deprecated from what I remember

Never understood our need for them for longer than half a day after
getting it explained to me.  I guess that's my fault.  Anyway, the less
we use them, the better.

Hacks exploiting deprecated GObject features would be a bad idea.
Perhaps we can hack something up that doesn't.

> - "array" properties - would need extra layer/tweaks for compatibility

I hated them from day one, tried to kill them, lost the argument.

> - link properties - would need special handling

Hard or not?

> - different limitations for type names and properties names

What to do?

Our naming rules and conventions are weakly documented.

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

So most QOM properties would be based on a GObject property, but some
wouldn't be, correct?

>            If there is enough interest, I will keep investigating. But
> for now, helping with meson seems more urgent.


/me warily eyes the monster lurking in the review queue...


reply via email to

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