Re: [RFC PATCH 001/134] qom: Introduce object_new_child()

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Jul 13, 2026 at 07:15:34PM +0100, Peter Maydell wrote:
> On Mon, 13 Jul 2026 at 17:50, Richard Henderson
> <richard.henderson@linaro.org> 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 <armbru@redhat.com>
> > > Link: https://lore.kernel.org/qemu-devel/87jyr3w9tc.fsf@pond.sub.org/
> > > Assisted-by: Kiro
> > > Signed-off-by: Alexander Graf <graf@amazon.com>
> > > ---
> > >   include/qom/object.h | 25 +++++++++++++++++++++++++
> > >   qom/object.c         | 13 +++++++++++++
> > >   2 files changed, 38 insertions(+)
> >
> > Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> >
> > > +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 :|