From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lnrxy-0004cQ-AP for mharc-grub-devel@gnu.org; Sun, 29 Mar 2009 06:10:10 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lnrxv-0004ac-H8 for grub-devel@gnu.org; Sun, 29 Mar 2009 06:10:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lnrxu-0004ZW-F3 for grub-devel@gnu.org; Sun, 29 Mar 2009 06:10:06 -0400 Received: from [199.232.76.173] (port=57088 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lnrxt-0004Z9-Pc for grub-devel@gnu.org; Sun, 29 Mar 2009 06:10:05 -0400 Received: from mail.nexedi.com ([91.121.25.85]:35489 helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lnrxs-0000Fa-Uw for grub-devel@gnu.org; Sun, 29 Mar 2009 06:10:05 -0400 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id B099D3D9F8 for ; Sun, 29 Mar 2009 12:10:02 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sun, 29 Mar 2009 19:09:56 +0900 User-Agent: KMail/1.9.10 References: <49CF4200.7010500@nic.fi> In-Reply-To: <49CF4200.7010500@nic.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903291909.56201.okuji@enbug.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] Split of the normal mode X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 10:10:08 -0000 On Sunday 29 March 2009 18:40:16 Vesa J=E4=E4skel=E4inen 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. Wh= at=20 is the motivation behind? What is the real benefit for the user? =46rom my point of view, it is wrong to force the user to manually load mod= ules,=20 generally. This includes writing "insmod" in config files. Look at Linux. I= t=20 is quite rare to execute insmod or modprobe directly. Most of the time,=20 modules are loaded on demand. This is the user-friendliness. You should select compile-time "loading" (i.e. linking) whenever possible. = If=20 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. =46YI, I am planning to make a full review of recent changes (i.e. all chan= ges=20 made after I stopped reviewing every patch), and trash/revert/rewrite/blame= =20 everything I don't like. Changes made for no good reason must be all=20 reverted. In brief, I take back the leadership of this project for general directions= =2E=20 =46or some subsystems (e.g. the coreboot support), I continue leaving the=20 responsibility to those who know better or are more active. Once the curren= t=20 code is reviewed and fixed (at some degree), I will make a new release. Any objection? Regards, Okuji