On 10.07.26 08:25, Markus Armbruster wrote: > "Graf (AWS), Alexander" <[email protected]> writes: > >> Hi Markus, > [...] > >> 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? > We do have such convenience functions at the QOM layer: object_new() and > object_property_add_child() etc., are basic building blocks, and > object_new_with_props() etc. combine them in useful ways. > > We don't have such convenience functions at the qdev layer. Can't see > why we couldn't add them. > > Number of orphaned device types I see by bus_type: > > 69 busless > 15 ISA > 33 PCI > 11 SSI > 209 System > 2 apple-desktop-bus > 23 i2c-bus > 2 sd-bus > 1 spapr-vio-bus > 2 usb-bus > > Again, not a problem with the device types, but the code that creates > and realizes them. > > Bus types commonly provide a layer above qdev for that. Perhaps these > layers could also use convenience functions to more easily deal with > setting the QOM parent.
I think the crux of the problem is that we ended up inheriting creation APIs that didn't necessarily express a clear parent/child relationship, so we end up orphaning these type of objects in the QOM tree. So the *real* answer IMHO is to rebuild all these APIs into something that enforces that. This way we also won't have new offenders sneaking in. I won't be able to spend the weeks it requires to do this by hand, but I can have a stab at it with AI - which is likely much more reliable at getting this done correctly than me too :). I can post it as RFC and then we decide whether we want to take it or leave it. Alex
