On Mon, Jul 13, 2026 at 07:15:34PM +0100, Peter Maydell wrote: > On Mon, 13 Jul 2026 at 17:50, Richard Henderson > <[email protected]> wrote: > > > > On 7/11/26 15:34, Alexander Graf wrote: > > > We already have two ways of creating a QOM object with a parent set > > > from birth: object_initialize_child() for objects embedded in the > > > parent struct, and object_new_with_props() for heap-allocated objects > > > that also want a list of string properties applied. What we do not > > > have is the plain heap-allocated dual of object_initialize_child(): > > > create the object, add it as a child<> of a given parent under a given > > > name, and hand the reference to the parent. > > > > > > Board and composite-device code that heap-allocates children today > > > therefore either open-codes object_new()+object_property_add_child() > > > +object_unref(), or skips the parenting step entirely and lets > > > device_set_realized() dump the object into /machine/unattached. > > > > > > Add object_new_child(parent, id, typename) as that missing primitive. > > > The reference created by object_new() is transferred to the parent's > > > child<> property, so on return the sole reference is held by @parent > > > and the caller does not need to unref. Later patches build the qdev > > > and per-bus creation helpers on top of this. > > > > > > Suggested-by: Markus Armbruster <[email protected]> > > > Link: https://lore.kernel.org/qemu-devel/[email protected]/ > > > Assisted-by: Kiro > > > Signed-off-by: Alexander Graf <[email protected]> > > > --- > > > include/qom/object.h | 25 +++++++++++++++++++++++++ > > > qom/object.c | 13 +++++++++++++ > > > 2 files changed, 38 insertions(+) > > > > Reviewed-by: Richard Henderson <[email protected]> > > > > > +Object *object_new_child(Object *parent, const char *id, > > > + const char *typename) > > > +{ > > > + Object *obj; > > > + > > > + g_assert(parent); > > > + g_assert(id); > > > > Of course, typename can't be null either. > > These asserts are of the "not very useful" kind, as well -- > if either of these are NULL we're going to crash pretty quickly, > and then the debugger backtrace will point you at your programming > error. Asserts are most useful when they turn non-obvious bugs > into obvious bugs or turn "happens a long time later than when the > problem is" bugs into "happens very close to when the problem is". > bugs.
For the 'id', we ought to call id_wellformed, and report an error if it fails, which implies an "Error **errp" arg for this method too. 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 :|
