On Fri, Oct 23, 2026 at 12:50:24PM +0100, Peter Maydell wrote: > On Fri, 23 Oct 2026 at 12:08, Daniel P. Berrangé <[email protected]> wrote: > > The memory backends are all implementing the UserCreatable > > interface, which provides a "complete" method where they > > could gracefully report lack of the feature via 'errp'. > > I didn't realize UserCreatable was a thing. It seems unfortunate > that we have accumulated three different kinds of object > creation/destruction life cycle: > > - instance_init / instance_finalize
This is all stuff that is supposed to be basic self contanied initialization/cleanup with no side effects or dependencies, and impossible to fail, which is pretty clear semantics. During init, no external properties have been set yet, and during finalize it is already disconnected from the QOM tree. Essentially these should be basic memory allocs/free, mutex inits/destroys, setting default int values if non-zero, etc. > - instance_init / realize / unrealize / instance_finalize > - instance_init / complete / prepare_delete / instance_finalize These two have clear overlap in that they both take place after user specified properties have been set, and deal with types of initialization/setup/cleanup that can fail and have external depedencies. UserCreatable has another aspect in that it is the witness flag for whether a QOM type is permissible to create using -object / object_add. I've periodically wondered if we could make them the same, but the realize/unrealize phases have significantly more complexity and dependancies than the complete/prepare_delete and most notably, 'realize' has a 'bus' parameter. I think that an approach to unification would end up with the 'Device' class implementing UserCreatable and providing a 'complete' method which in turn called the 'realize' method. IOW, nothing much would really change in terms of impls, as all Device subclasses would carry on using realize/unrealize. It would merely make Device tree available to -object/object_add. There are probably quite a few edge case problems hiding in there though if one were to actually try to do this, so the pragmatic option is really to ignore this all and accept the different APIs for Device vs non-Device QOM. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
