Marc-André Lureau <marcandre.lur...@gmail.com> writes: > 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
Lame. 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, though. > - 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. Yes. /me warily eyes the monster lurking in the review queue... [...]
