Il 20/03/2013 00:44, Peter Maydell ha scritto: > On 19 March 2013 23:35, Paolo Bonzini <pbonz...@redhat.com> wrote: >> > Il 19/03/2013 23:34, Peter Maydell ha scritto: >>> >> On 19 March 2013 22:23, Paolo Bonzini <pbonz...@redhat.com> wrote: >>>> >>> So, okay to put these in hw/arm and then I'll work on patches moving >>>> >>> cpu_arm_init to a*mpcore.c? >>> >> >>> >> Wrong way round. If you can't put the cpu_arm_init into the a*mpcore >>> >> in a way that doesn't make you want to put them in hw/arm/ then >>> >> it should wait until we've QOMified the CPU cores sufficiently >>> >> that we can do it properly. >> > >> > Does that include calling the CPU constructor something else than >> > cpu_arm_init (which is defined in target-arm/)? For me that would be >> > enough to put it in hw/arm. > The CPU should be created (and thus initialised and realised) the same > way as any other QOM object or device; the containers shouldn't need > to call cpu_arm_init directly.
ARM is already quite good in that respect. However, until all architectures are converted cpu_*_init needs to remain because of user-mode targets (where the CPUs are created by common code, there is no board to encapsulate the target-specific differences). IMHO waiting for the demise of cpu_*_init is putting the cart before the horse, or another similar proverb. (Also, I don't see much difference between using a function in target-ARCH and using a TYPE_FOO define from target-ARCH. They are the same thing masked through RTTI. hw/ARCH should really be the bridge between target-ARCH and hw/everything-else, and a*mpcore.c fits in that description). Paolo
