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.