On Wed, 4 Mar 2026 at 12:25, Markus Armbruster <[email protected]> wrote: > We might be at a crossroads here. > > Paul Brook designed qdev around "a device plugs into some bus, and may > provide buses". To make this work, he added a main system bus to serve > as root of a single tree. > > The parent of a device in that tree is the bus it plugs into, and the > parent of a bus is the device that provides it, except for the main > system bus, which has no parent. "info qtree" shows this tree. > > Note a machine had just this one system bus back then. > > The system bus isn't something hardware people would call a bus. > > The qtree is a qdev thing. It is *not* the QOM composition tree ("info > qom-tree /"). > > We actually abandoned "a device plugs into some bus" a long time ago. > Moe on that below. > > Qdev was later rebased onto QOM, as follows. > > A bus QOM type is a subtype of "bus". > > A device QOM type is a subtype of "device". > > If a device type has a @bus_type, then it plugs into a bus of that QOM > type. Such a concrete device is commonly[*] not a direct subtype of > "device". Instead, it's a subtype of the abstract device that plugs > into that bus type. Example: "isa-serial" is a direct subtype of > "isa-device", and it inherits its bus type "ISA" from there. > > If a device has no @bus_type, it doesn't plug into any bus. It doesn't > show up in "info qtree" (it does in "info qom-tree", of course). > Example: "serial" is a direct subtype of "device". > > This lets us build devices from components without having to make up > buses to connect them. Example: "isa-serial" has a direct QOM child of > type "serial". Good! > > Except infrastructure useful to such bus-less devices lives in sysbus, > where bus-less devices can't access it. This tempts us to make devices > sysbus devices just to be able to use the infrastructure, and to create > additional sysbuses.
There is only one sysbus -- it is impossible to create more than one, and there wouldn't be much point in creating a second one anyway. > We can elect to go down this path further: make more sysbus devices. > Create more sysbuses. If this is the right path, then bus-less devices > were a mistake, and we should consider eliminating them. > > Or we can pick the other branch: put the infrastructure where bus-less > devices can use it. If this is the right path, then sysbus is > obsolescent. I do think that at some point it would be good to move all that stuff into the base "device" class, and drop sysbus. The real problem, though, is reset. Currently reset propagates along the qtree (the tree of buses). So something (like TYPE_SERIAL, and also like CPU objects) that is a direct child of TYPE_DEVICE does not get automatically reset. The major overriding reason why (as it currently stands) I favour making things sysbus devices and not plain devices is that devices that don't get reset are either broken or need all their users to take extra steps that most don't take, or do in a weird way. We can't just push the reset handling into TYPE_DEVICE because by definition it is tied to "being a thing on a bus, i.e. the sysbus". Disentangling reset is extremely painful -- I don't even know what it ought to be doing. Maybe propagating along the QOM tree? So for now, we muddle along. -- PMM
