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
