Re: [Qemu-devel] [PULL 04/11] target-i386: Rename cpu_x86_init() to cpu_x86_init_user()

[Andreas Färber]

Am 26.02.2015 um 16:59 schrieb Eduardo Habkost:
> On Wed, Feb 25, 2015 at 11:06:55PM +0100, Andreas Färber wrote:
>> Am 25.02.2015 um 20:58 schrieb Eduardo Habkost:
>>> The function is used only for CONFIG_USER, so make its purpose clear.
>>>
>>> Reviewed-by: Paolo Bonzini <address@hidden>
>>> Signed-off-by: Eduardo Habkost <address@hidden>
>>> ---
>>>  target-i386/cpu.c | 2 +-
>>>  target-i386/cpu.h | 4 ++--
>>>  2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> Please don't. I happily got all architectures aligned that it's at least
>> cpu_something_init, and it only happens to be user-only for x86. It is
>> rather the legacy function that was used in both system and user.
> 
> If that's a legacy function, what are the steps you plan to follow to
> eliminate it? I would be glad to help eliminating legacy code.
> 
> Initialization of CPUs in *-user and *-softmmu is different in i386, so
> we are going to have different code for both. How do you think I should
> name the *-user-specific CPU init function in target-i386, then?

I would prefer to leave its name as it is (unless we are renaming all,
which would probably be a waste of effort giving the next steps) and
simply not use it in PC code. If you want to enforce this, you could
#ifdef CONFIG_USER_ONLY it.

For some targets - as can be seen in your uc32 patch - there is already
a cpu_generic_init() that calls into the CPUClass hooks of the given CPU
type. I would like to call that from linux-user directly (or from a
lightweight wrapper to be shared between linux-user and bsd-user, I
assume we're going need some target-specific #ifdefs) and drop
cpu_init() in its current form. In particular I want to somehow move the
realized=true part out of it, which means either inlining it into dozens
of machines or finishing the recursive realization work so that we only
need one central realized=true for /machine.

My branch with the last realize_children code unfortunately ran into
conflicts with hotplug handler code and recursive un-realization and
hasn't been rebased in months. Paolo's comment had been that we would
need to assure by reordering (or at least prove it not-yet-necessary by
assertions) that the qdev-bus topology in addition to the QOM parents
have been realized before a given child device gets realized.

Additionally, /machine is its own type iirc, so will either need to
become a device or have its own "realized" property implementation
iterating over its direct, unassigned and peripheral children.

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)