Re: Call to clean up QOM onboard devices lacking a parent

["Graf (AWS), Alexander" <graf@amazon.de>]

On 10.07.26 08:25, Markus Armbruster wrote:
> "Graf (AWS), Alexander" <graf@amazon.de> 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