qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU


From: Claudio Fontana
Subject: Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU
Date: Wed, 18 Nov 2020 14:48:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 11/18/20 1:48 PM, Eduardo Habkost wrote:
> On Wed, Nov 18, 2020 at 11:29:35AM +0100, Claudio Fontana wrote:
>> apply this to the registration of the cpus accel interfaces,
>>
>> but this will be also in preparation for later use of this
>> new module init step to also defer the registration of the cpu models,
>> in order to make them subclasses of a per-accel cpu type.
>>
>> Signed-off-by: Claudio Fontana <cfontana@suse.de>
>> ---
> [...]
>> +    /*
>> +     * accelerator has been chosen and initialized, now it is time to
>> +     * register the cpu accel interface.
>> +     */
>> +    module_call_init(MODULE_INIT_ACCEL_CPU);
> 
> I don't get why we would use a new module initialization level

To have a clear point in time after which all accelerator interface 
initialization is done.
It avoids to have to hunt down the registration points spread around the code 
base.
I'd turn it around, why not?

> for this.  If the accelerator object was already created, we can
> just ask the existing accel object to do whatever initialization
> step is necessary.
> 
> e.g. we can add a AccelClass.cpu_accel_ops field, and call:
> 
>    cpus_register_accel(current_machine->accelerator->cpu_accel_ops);
> 

_When_ this is done is the question, in my view, where the call to the 
registration is placed.

After adding additonal operations that have to be done at "accelerator-chosen" 
time, it becomes more and more difficult to trace them around the codebase.

Thanks,

Claudio







reply via email to

[Prev in Thread] Current Thread [Next in Thread]