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?) >> 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. >> 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?). 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. thanks -- PMM