|
From: | Paolo Bonzini |
Subject: | Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU |
Date: | Wed, 25 Nov 2020 10:30:48 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
On 25/11/20 10:21, Claudio Fontana wrote:
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.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"?
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
[Prev in Thread] | Current Thread | [Next in Thread] |