Hi On Wed, Jan 22, 2020 at 4:25 PM Markus Armbruster <arm...@redhat.com> wrote: > > Alex Bennée <alex.ben...@linaro.org> writes: > > > Marc-André Lureau <marcandre.lur...@gmail.com> 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
