Hi, Christoph
On 23/07/2024 22:33, Christoph Hellwig wrote:
On Tue, Jul 23, 2024 at 04:32:36PM +0800, Youling Tang wrote:
Providing module_subinit{_noexit} and module_subeixt helps macros ensure
that modules init/exit match their order, while also simplifying the code.
The three macros are defined as follows:
- module_subinit(initfn, exitfn,rollback)
- module_subinit_noexit(initfn, rollback)
- module_subexit(rollback)
`initfn` is the initialization function and `exitfn` is the corresponding
exit function.
I find the interface a little confusing. What I would have expected
is to:
- have the module_subinit call at file scope instead of in the
module_init helper, similar to module_init/module_exit
- thus keep the rollback state explicitly in the module structure or
similar so that the driver itself doesn't need to care about at
all, and thus remove the need for the module_subexit call.
module_init(initfn)/module_exit(exitfn) has two definitions (via MODULE):
- buindin: uses do_initcalls() to iterate over the contents of the specified
section and executes all initfn functions in the section in the order in
which they are stored (exitfn is not required).
- ko: run do_init_module(mod)->do_one_initcall(mod->init) to execute initfn
of the specified module.
If we change module_subinit to something like this, not called in
module_init,
```
static int init_a(void)
{
...
return 0;
}
static void exit_a(void)
{
...
}
subinitcall(init_a, exit_a);
static int init_b(void)
{
...
return 0;
}
static void exit_b(void)
{
...
}
subinitcall(init_b, exit_b);
```
Not only do we want to ensure that exit is executed in reverse order of
init, but we also want to ensure the order of init.
This does not guarantee the order in which init will be executed (although
the init/exit order will remain the same)
Tanks,
Youling.
