qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] List of files containing devices which have not been QOMified
Date: Tue, 6 Nov 2018 23:05:12 +0000

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?)

>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]