Re: [Qemu-devel] List of files containing devices which have not been QOMified

[Paolo Bonzini]

On 07/11/2018 00:05, Peter Maydell wrote:
> On 6 November 2018 at 19:46, Paolo Bonzini <address@hidden> 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.