On 11/24/20 10:31 PM, Eduardo Habkost wrote:
> On Tue, Nov 24, 2020 at 09:13:13PM +0100, Paolo Bonzini wrote:
>> On 24/11/20 17:22, Claudio Fontana wrote:
>>> +static void x86_cpu_accel_init(void)
>>> {
>>> - X86CPUAccelClass *acc;
>>> + const char *ac_name;
>>> + ObjectClass *ac;
>>> + char *xac_name;
>>> + ObjectClass *xac;
>>> - acc = X86_CPU_ACCEL_CLASS(object_class_by_name(accel_name));
>>> - g_assert(acc != NULL);
>>> + ac = object_get_class(OBJECT(current_accel()));
>>> + g_assert(ac != NULL);
>>> + ac_name = object_class_get_name(ac);
>>> + g_assert(ac_name != NULL);
>>> - object_class_foreach(x86_cpu_accel_init_aux, TYPE_X86_CPU, false,
>>> &acc);
>>> + xac_name = g_strdup_printf("%s-%s", ac_name, TYPE_X86_CPU);
>>> + xac = object_class_by_name(xac_name);
>>> + g_free(xac_name);
>>> +
>>> + if (xac) {
>>> + object_class_foreach(x86_cpu_accel_init_aux, TYPE_X86_CPU, false,
>>> xac);
>>> + }
>>> }
>>> +
>>> +accel_cpu_init(x86_cpu_accel_init);
>>
>> If this and cpus_accel_ops_init are the only call to accel_cpu_init, I'd
>> rather make them functions in CPUClass (which you find and call via
>> CPU_RESOLVING_TYPE) and AccelClass respectively.
>
> Making x86_cpu_accel_init() be a CPUClass method sounds like a
> good idea. This way we won't need a arch_cpu_accel_init() stub
> for non-x86.
I really don't like stubs, and trying to link the proper ones for each of the
targets we need to build.
It screams "this hasn't been refactored properly yet - sorry!"
If we could avoid them it would be a clear benefit from my perspective.
>
> accel.c can't use cpu.h, correct? We can add a:
>
> CPUClass *arch_base_cpu_type(void)
> {
> return object_class_by_name(CPU_RESOLVING_TYPE);
> }
>
> function to arch_init.c, to allow target-independent code call
> target-specific code.
>
Ciao,
Claudio
