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

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

On 09/11/2018 10:31, Peter Maydell wrote:

> On 9 November 2018 at 10:17, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> 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).
> 
>>> 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);
> 
> I think the code I saw that looked like a non-QOMified
> device was cpu_timer_create().
> 
> The ResetData stuff is just working around the fact that
> CPUs don't get reset unless the board code does something
> to arrange for that to happen, so it's OK. (I would like
> us to eventually tackle properly overhauling our approach
> to reset, but that's a separate body of work.)

Ah okay. The above timers are certainly internal CPU timers rather than external, so
should they still be QOMified? How are timers modelled for other CPUs?


ATB,

Mark.