Re: [PATCH] Split of the normal mode

[Yoshinori K. Okuji]

On Sunday 29 March 2009 18:40:16 Vesa Jääskeläinen wrote:
> Bean wrote:
> > Hi,
> >
> > This patch split the function of normal mode into small modules, here
> > is a summary:
> >
> > 1, Move dynamic command loader to commands/dyncmd.c (dyncmd.mod)
> > 2, Move automatic fs loader to fs/autofs.c (autofs.mod)
> > 3, Split normal mode into three major parts:
> > parser/normal - normal mode parser (nparser.mod)
> > reader/normal - normal mode command line reader (nreader.mod)
> > menu/text - menu viewer (tmenu.mod)
> > 4, Generic menu function move to menu/menu.c and menu/menu_viewer.c.
> > (menu.mod) 5, Misc function move to lib/misc.c lib/completion.c
> > (misc.mod)
> > 6, setjmp function move to lib/i386, lib/x86_64, lib/powerpc and
> > lib/sparc64 (setjmp.mod)
>
> Umh... I could somewhat agree with moving text menu out of normal.mod.
> But...
>
> I feel we have passed the over engineering milestone sometime ago... and
>  I am not frankly happy about that...
>
> Changes like this just make it a) harder to maintain, b) bigger overall
> size impact, c) as a plus more modular approach...
>
> I also fear that we seem to be missing some lead for the project that
> could use his authority to make decisions...

Indeed. I don't understand this tendency about splitting modules at all. What 
is the motivation behind? What is the real benefit for the user?

From my point of view, it is wrong to force the user to manually load modules, 
generally. This includes writing "insmod" in config files. Look at Linux. It 
is quite rare to execute insmod or modprobe directly. Most of the time, 
modules are loaded on demand. This is the user-friendliness.

You should select compile-time "loading" (i.e. linking) whenever possible. If 
a function is loaded eventually, it should be linked at compile time.

You should select automatic loading, if you need runtime linking.

Manual loading should be considered evil, in principle.

FYI, I am planning to make a full review of recent changes (i.e. all changes 
made after I stopped reviewing every patch), and trash/revert/rewrite/blame 
everything I don't like. Changes made for no good reason must be all 
reverted.

In brief, I take back the leadership of this project for general directions. 
For some subsystems (e.g. the coreboot support), I continue leaving the 
responsibility to those who know better or are more active. Once the current 
code is reviewed and fixed (at some degree), I will make a new release.

Any objection?

Regards,
Okuji