"Graf (AWS), Alexander" <[email protected]> writes:
> 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.
The appended trivial patch will keep new offenders out. Drawback: it
breaks almost everything due to existing offenders ;)
Kidding aside, the code it deletes was a mistake. We likely added it
for quicker initial conversions. The technical debt's compound interest
has been piling up ever since.
> 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.
The part that requires actual thought is the hardware modeling: what's
part of what.
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index e2aab3d1fc..058f89fa55 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -493,15 +493,6 @@ static void device_set_realized(Object *obj, bool value,
Error **errp)
goto fail;
}
- if (!obj->parent) {
- gchar *name = g_strdup_printf("device[%d]", unattached_count++);
-
- object_property_add_child(machine_get_container("unattached"),
- name, obj);
- unattached_parent = true;
- g_free(name);
- }
-
hotplug_ctrl = qdev_get_hotplug_handler(dev);
if (hotplug_ctrl) {
hotplug_handler_pre_plug(hotplug_ctrl, dev, &local_err);
