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

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

On 06/11/2018 18:43, Peter Maydell wrote:

> I had an idea for how to get a rough list of source files
> containing devices that haven't been QOMified. The theory
> is that a pre-QOM device generally has an "init" function
> which allocates memory for the device struct. So looking in
> hw/ for files which call g_new*() or g_malloc*() should get
> us all the non-QOM devices (as well as a pile of false
> positives, of course). The following link is the result of
> doing that and then eyeballing the results for false positives
> and throwing those out. It might have missed one or two
> files or included one or two by mistake. But I think it's
> pretty close, and it seems to have caught all the obvious
> ones I knew about. There are 61 files on this list.
> 
> I am also suspicious about hw/bt/ but don't know enough
> about that subsystem to say if it could benefit from
> using QOM objects more.

> hw/ppc/prep.c

I had a quick look at this and AFAICT it's in the old -M prep code which is
deprecated and hopefully scheduled for removal soon, so I think we can leave this one.

> hw/sparc64/sparc64.c

This would appear to be from sparc64_cpu_devinit() which sets up a ResetData
structure like this:

    reset_info = g_malloc0(sizeof(ResetData));
    reset_info->cpu = cpu;
    reset_info->prom_addr = prom_addr;
    qemu_register_reset(main_cpu_reset, reset_info);

Presumably this can now be handled by using CPUClass's reset() method? The prom_addr
field is a per-machine parameter that is used to derive the starting PC for the CPU,
so I believe converting this to a qdev parameter on the SPARC CPU should suffice.


ATB,

Mark.