On 07/11/2018 00:05, Peter Maydell wrote: > On 6 November 2018 at 19:46, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 06/11/2018 19:43, Peter Maydell wrote: >>> hw/core/ptimer.c >> >> Not a device. > > Indeed not, but it could be a QOM object I guess (would > that gain us anything?)
I don't know, it seems to me more like a generic high-level abstraction around QEMUTimer. >>> hw/i2c/bitbang_i2c.c >> >> TYPE_GPIO_I2C? > > That part is, but bitbang_i2c_init() creates an object > which isn't a QOM object and is used by some other i2c devices. Ah, I see. Then I think it is in the same family as AHCIState. >>> hw/ide/ahci.c >> >> Even though AHCIState is not a QOM object, all of its users are >> (TYPE_SYSBUS_AHCI is in this file, TYPE_ICH9_AHCI is in hw/ide/ich.c) > > Mmm, this is one of those which I was unsure about so > put on the list anyway. > > Overall something that occurs to me is that I'm not sure > what exactly (other than tidiness) we gain from converting > remaining non-QOM devices. In some of the other cases I've > looked at (like sysbus init methods or old_mmio users) we > get to complete an API transition and remove the old code. > For a non-QOM device, how much does it hurt us that they're > lying around in the codebase? We might do better to > specifically target APIs we'd like to deal with (like > direct uses of vmstate_register, maybe?). Yes, those are ugly and are definitely a sign of a legacy device (non-qdev even before QOM). serial_mm_init is the main example as you point out below. Paolo > Some bits I would definitely like to see cleaned up are > the things like the mmio version of the 16550 UART code > in hw/char/serial.c -- that not being QOMified has > knock-on effects in making other devices that would > like to basically just be 16550-wrappers harder to > write in a clean way.