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