On Wed, 25 May 2022 at 10:51, Damien Hedde <damien.he...@greensocs.com> wrote: > On 5/24/22 19:44, Mark Cave-Ayland wrote: > > Sorry for coming late into this series, however one of the things I've > > been thinking about a lot recently is that with the advent of QOM and > > qdev, is there really any distinction between TYPE_DEVICE and > > TYPE_SYS_BUS_DEVICE anymore, and whether it makes sense to keep > > TYPE_SYS_BUS_DEVICE long term. > > On QAPI/CLI level there is a huge difference since TYPE_SYS_BUS_DEVICE > is the only subtype of TYPE_DEVICE which is subject to special > treatment. It prevents to plug a sysbus device which has not be allowed > by code and that's what I want to get rid of (or workaround by allowing > all of them).
Yes, but the fact that TYPE_SYS_BUS_DEVICE is a special subclass is an accident of history. At some point we really ought to tidy this up so that any TYPE_DEVICE can have MMIO regions and IRQs, and get rid of the subclass entirely. This isn't trivial, for reasons including problems with reset handling, but I would prefer it if we didn't bake "sysbus is special" into places like the QMP commands. More generally, I don't think that the correct answer to "is this device OK to cold-plug via commandline and QMP is "is it a sysbus device?". I don't know what the right way to identify cold-pluggable devices is but I suspect it needs to be more complicated. > I'm note sure what you mean by identification and enumeration. I do not > do any introspection and rely on knowing which mmio or irq index > corresponds to what. The "id" in `device_add` allows to reference the > device in following commands. This is then baking in a device's choices of MMIO region ordering and arrangement and its IRQ numbering into a user-facing ABI. I can't say I'm very keen on that -- it would block us from being able to do a variety of refactorings and cleanups. -- PMM
