Am 27.02.2015 um 15:40 schrieb Andreas Färber: > Hi Eduardo, > > Am 26.02.2015 um 21:37 schrieb Eduardo Habkost: >> This series changes cpu_init() to return a CPU QOM object, and changes >> existing >> arch-specific code to use the corresponding arch-specific function instead of >> cpu_init(). >> >> With this, the only remaining users of cpu_init() are linux-user and >> bsd-user. >> >> Eduardo Habkost (4): >> target-unicore32: Make uc32_cpu_init() return UniCore32CPU >> m68k: Use cpu_m68k_init() >> unicore32: Use uc32_cpu_init() > > This part looks good to me. At the time, I propagated *CPU only for > those machines that needed it for function calls or field accesses. > >> cpu: Make cpu_init() return QOM object > > As for this patch, the Coccinelle based approach looks cool! However I > would like to give this a bit more thought as to whether 1) this causes > churn with regards to the next steps I outlined, and 2) whether more > simplifications can be done while at it. Could be done as follow-ups.
Not hearing any objection from machine maintainers, I've gone ahead and applied the fourth patch as well: https://github.com/afaerber/qemu-cpu/commits/qom-cpu One of the concerns I had was whether we might use cpu_generic_init() in the macro directly, where applicable. But that seems to depend on whether machines will continue to use FooCPU *cpu_foo_init(), which depends on how we proceed with CPU (hot-plug) remodeling, etc. Thanks, Andreas > > Let's also keep in mind that target-tilegx patches are on the list. > > Regards, > Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)
