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 >
Hi Paolo, not super-related to the context above, during the implementation I am trying to offer accel/accel-softmmu.c accel/accel-common.c accel/accel-user.c But I don't seem able to use CONFIG_USER_ONLY in accel-common.c . in accel/meson.build I am saying common_ss.add(files('accel-common.c')) softmmu_ss.add(files('accel-softmmu.c')) user_ss.add(files('accel-user.c')) But this doesn't work, if I use common_ss. If I use specific_ss, it works. So the term "common" is a bit overloaded, it means stuff for libcommon and such, not common between softmmu and user, right? Ciao, Claudio