qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU


From: Claudio Fontana
Subject: Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU
Date: Wed, 25 Nov 2020 11:42:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 11/25/20 10:30 AM, Paolo Bonzini wrote:
> On 25/11/20 10:21, Claudio Fontana wrote:
>> Hi Paolo,
>>
>> in RFC v5 , module init for ACCEL_CPU is not conditional anymore, right?
>> But the fact that its behavior depends on current_accel() still disqualifies 
>> it?
>> It is called right after the accelerator is chosen and initialized
>> in RFC v5, this still is "in the middle of the machine creation sequence"?
> Yes, machine creation basically starts after command line parsing, or 
> perhaps even _with_ command line parsing.  Basically once the user can 
> control the flow it is already too late.
> 
>> I am trying to find the actual things to fix, since when doing RFC
>> v5  I tried to specifically address two points:
>>
>> 1) no if () inside module init functions
>>
>> 2) no proliferation of module init functions
>>
>> which I accomplished via AccelClass extension to user mode, current_accel(), 
>> and class lookup.
> 
> Yes, the rest is great, I'm just not sure that MODULE_INIT_ACCEL_CPU is 
> useful and if virtual functions on accel and CPU_RESOLVING_TYPE can 
> achieve the same.
> 
>> If MODULE_INIT_ACCEL_CPU remains an option, where would you like to see the 
>> call so that it is not "in the middle"?
> 
> No later than the runstate_init() call, roughly.
> 
> Paolo
> 
> 

Aha! Then that solves it, I don't think it is feasible to put it that early 
with the meaning I intended for it.

Thanks for clarifying this,

Claudio



reply via email to

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