All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>
Subject: Re: [RFC PATCH] hw/core: Avoid attaching qdevs to /machine/unattached if they have a bus
Date: Tue, 24 Feb 2026 09:47:30 +0000	[thread overview]
Message-ID: <aZ1zsoyKcD1ChK--@redhat.com> (raw)
In-Reply-To: <874ind5da6.fsf@pond.sub.org>

On Thu, Feb 19, 2026 at 09:49:05AM +0100, Markus Armbruster wrote:
> Thomas Huth <thuth@redhat.com> writes:
> 
> > From: Thomas Huth <thuth@redhat.com>
> >
> > We still have a lot of devices that end up in /machine/unattached in
> > case the caller forgot to use object_property_add_child() to add it
> > to a proper location in the QOM tree.
> 
> This is QOM papering over sloppy modeling.  Predictably, it has enabled
> us to remain sloppy slobs.
> 
> I think the decision to paper over sloppiness to get QOM off the ground
> quickly was defensible back then.  It's a lot less defensible now that
> QOM has been off the ground for more than a decade.
> 
> I believe people are by and large unaware of the need to add children.
> This risks further accumulation of technical debt.

IMHO, it is slightly more subtle - people believe they are already
adding children.

Consider this code.

    port92 = isa_create_simple(isa_bus, TYPE_PORT92);

my reading of that is that I'm creating a "port92" device that is a
child of "isa_bus". Why would I need to tell QEMU that it is a child
for a second time ?

If I trace calls through isa_create_simple I get to a call to:

   qdev_realize_and_unref(dev, parent, errp);

and once I again I'm left wondering why I would need to tell
QEMU 'dev' is a child of 'parent' a second time.

Of course I know the answer. We need to give a name for the
child and it isn't trivial to "do the right thing" to invent
an automatic name.

Still, overall I'm inclined to largely blame our API designs for
not guiding people into doing the right thing.


Picking another random unattached set of objects "smbus-eeprom"
I again find they've being created with qdev_realize_and_unref.

Pick another unattached device 'i8259_init_chip', and again
we end up calling into qdev_realize_and_unref()


It feels like qdev_realize_and_unref() is a common point of
blame in unattached devices. IMHO it ought to be taking a
"const char *name" parameter.

There are 104 calls to qdev_realize_and_unref(), but it is in
the call path of many more wrapped calls.

A big-ish job to convert them all, so perhaps we need to add
a parallel

   qdev_realize_and_unref_child(...)

with the new 'name' parameter, and incrementally convert stuff,
though ideally a conversion that doesn't last "forever" like
so many of our conversion tasks.

> To really put a stop to it, we'd have to mark the existing misuses, then
> warn or crash on umarked misuse.

While marking / warning / crashing helps surface problems, I think
that fixing the API designs to guide developers at compile time is
more important.

> None of the above is an objection to your patch.

I guess even with the patch applied we can still identify broken
code by looking for any child with an "x-" property name.


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 :|



  reply	other threads:[~2026-02-24  9:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-17 16:40 [RFC PATCH] hw/core: Avoid attaching qdevs to /machine/unattached if they have a bus Thomas Huth
2026-02-19  8:49 ` Markus Armbruster
2026-02-24  9:47   ` Daniel P. Berrangé [this message]
2026-02-24 11:10     ` Peter Maydell
2026-02-24 12:22       ` Mark Cave-Ayland
2026-02-25  1:05         ` BALATON Zoltan
2026-02-26 11:58           ` Peter Maydell
2026-02-26 22:57             ` BALATON Zoltan
2026-03-08 17:56             ` Bernhard Beschow
2026-02-25  5:55         ` Philippe Mathieu-Daudé
2026-02-26 22:03           ` Bernhard Beschow
2026-02-24 11:43     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZ1zsoyKcD1ChK--@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.