Hi Markus, On 09.07.26 18:02, BALATON Zoltan wrote: > > On Thu, 9 Jul 2026, Markus Armbruster wrote: >> A QOM object must be the child of exactly one parent. This defines the >> QOM composition tree. The link from parent to child is a property of >> the parent, and therefore has a name that is unique within its parent. >> An object's canonical QOM path is these names on the path from root to >> object in the QOM composition tree separated by '/'. >> >> For devices: >> >> * If a device is plugged in with -device / device_add, and it has an ID, >> we make it a child of /machine/peripheral/ with name ID. If it >> doesn't have an ID, we make it a child of /machine/peripheral-anon/ >> with name device[N], where N counts up from zero. The canonical QOM >> path /machine/peripheral/ID is stable. The canonical QOM path >> /machine/peripheral-anon/device[N] isn't: it depends on the number of >> devices already there. >> >> * If a device is part of another device, it should be its child. The >> child's canonical QOM path is the parent's plus '/CHILD-NAME'. Stable >> as long as the parent's path and the child name are. >> >> * "Should" because we have a lot of code that fails to pick the parent. >> When such a device gets realized, we make it a child of >> /machine/unattached/ orphanage with name device[N], where N counts up >> from zero. The canonical QOM path /machine/unattached/device[N] >> depends on the number of children already in the orphanage, which >> makes it unstable. >> >> Letting code get away with not picking a parent was a mistake. I >> guess it "saved" us some thinking about what's part of what when >> converting existing devices to QOM. In other words, it enabled sloppy >> hardware modeling. We've been "saving" thinking ever since. >> >> I want /machine/unattached/ to be empty. If an onboard device isn't >> part of another device, put it into /machine/ with a sensible name. > > The last time this came up I've asked a few questions but did not get an > answer: > > 1. What's the use of the QOM composition tree? I never needed it and > apart > from being able to admire it in info qom-tree I don't know if it's used > for anything. For a long time I did not even know about info qom-tree > because I only needed info qtree and info mtree and rarely if ever > need to > look at the qom-tree. If it has no real use I'm happy to not think about > it. > > 2. What is a QOM parent? There were proposals to parent devices to their > bus if they have any, that's what qtree shows anyway. If it's something > else it should be better defined somewhere. > > Without getting answers for these questions I don't think I'm able to fix > the machines I maintain.
I'm also curious on whether there is anything that makes sysbus device spawns both easy (as they are today) and at the same time fully QOM parent compliant. I had a quick look at the vmapple machine and most of the offenders are sysbus devices I spawn via qdev_new(). Would you want all of these to get their parent declared via object_property_add_child()? If that's the case, why don't we introduce a new qdev_new_child() which does that automatically? Alex
