On Fri, 23 Oct 2026 at 13:37, Daniel P. Berrangé <[email protected]> wrote: > > 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.
No, it doesn't: the method signature is typedef void (*DeviceRealize)(DeviceState *dev, Error **errp); The qdev_realize() function takes a Bus pointer, but it doesn't get passed to the device itself, only used to call qdev_set_parent_bus(). (So arguably it would be better called "qdev_realize_and_parent()" but that's a bit unwieldy.) > 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. Probably. But I think the core reason we've ended up here is that we didn't have the two-stage init in the core Object type and so different subclasses have ended up implementing very similar requirements differently. So if we did care enough to tackle this I would favour pushing it up into Object. -- PMM
