Re: [PATCH 1/4] module: Add module_subinit{_noexit} and module_subeixt helper macros

Youling Tang
2024-07-29T01:46:49Z

On 27/07/2024 22:52, Theodore Ts'o wrote:
> On Fri, Jul 26, 2024 at 11:09:02AM -0700, Christoph Hellwig wrote:
>> On Fri, Jul 26, 2024 at 01:58:00PM -0400, Theodore Ts'o wrote:
>>> Yeah, that's my reaction as well. This only saves 50 lines of code in
>>> ext4, and that includes unrelated changes such as getting rid of "int
>>> i" and putting the declaration into the for loop --- "for (int i =
>>> ..."). Sure, that saves two lines of code, but yay?
>>>
>>> If the ordering how the functions gets called is based on the magic
>>> ordering in the Makefile, I'm not sure this actually makes the code
>>> clearer, more robust, and easier to maintain for the long term.
>> So you two object to kernel initcalls for the same reason and would
>> rather go back to calling everything explicitly?
> I don't oject to kernel initcalls which don't have any
> interdependencies and where ordering doesn't matter.
1. Previous version implementation: array mode (see link 1) :
Advantages:
- Few changes, simple principle, easy to understand code.
Disadvantages:
- Each modified module needs to maintain an array, more code.

2. Current implementation: explicit call subinit in initcall (see link 2) :
Advantages:
- Direct use of helpes macros, the subinit call sequence is
intuitive, and the implementation is relatively simple.
Disadvantages:
- helper macros need to be implemented compared to array mode.

3. Only one module_subinit per file (not implemented, see link 3) :
Advantage:
- No need to display to call subinit.
Disadvantages:
- Magic order based on Makefile makes code more fragile,
- Make sure that each file has only one module_subinit,
- It is not intuitive to know which subinits the module needs
and in what order (grep and Makefile are required),
- With multiple subinits per module, it would be difficult to
define module_{subinit, subexit} by MODULE, and difficult to
rollback when initialization fails (I haven't found a good way
to do this yet).

Personally, I prefer the implementation of method two.

Links:
[1]:
https://lore.kernel.org/all/20240711074859.366088-4-youling.tang@linux.dev/
[2]:
https://lore.kernel.org/all/20240723083239.41533-2-youling.tang@linux.dev/
[3]: https://lore.kernel.org/all/ZqKreStOD-eRkKZU@infradead.org/

Thanks,
Youling.