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

[Youling Tang]

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@xxxxxxxxx/
[2]: 
https://lore.kernel.org/all/20240723083239.41533-2-youling.tang@xxxxxxxxx/
[3]: https://lore.kernel.org/all/ZqKreStOD-eRkKZU@xxxxxxxxxxxxx/

Thanks,
Youling.