From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1BbhMO-0002rr-6w for mharc-grub-devel@gnu.org; Sat, 19 Jun 2004 11:02:24 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BbhMM-0002rV-SD for grub-devel@gnu.org; Sat, 19 Jun 2004 11:02:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BbhML-0002rJ-CV for grub-devel@gnu.org; Sat, 19 Jun 2004 11:02:22 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BbhML-0002rG-B4 for grub-devel@gnu.org; Sat, 19 Jun 2004 11:02:21 -0400 Received: from [212.43.237.68] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BbhL2-0007Ma-93 for grub-devel@gnu.org; Sat, 19 Jun 2004 11:01:00 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id B6DC7FFC30D0 for ; Sat, 19 Jun 2004 11:00:59 -0400 (EDT) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sat, 19 Jun 2004 17:05:00 +0200 User-Agent: KMail/1.6.1 References: <20040615113103.GA4639@artax.karlin.mff.cuni.cz> <874qp9dled.fsf@marco.marco-g.com> <20040618191411.GA30179@artax.karlin.mff.cuni.cz> In-Reply-To: <20040618191411.GA30179@artax.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406191705.01343.okuji@enbug.org> Subject: Re: Autoloading WAS: normal/cmdline bug & patch X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.4 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: Sat, 19 Jun 2004 15:02:23 -0000 So there are three ways for this approach: A. Load all modules at the start-up time. B. Load modules until a module succeeds to recognize a filesystem. C. Load an appropriate module using signatures or magic. A is very simple, but it always consumes memory unnecessarily. B is also simple enough, but it also may consume memory unnecessarily. C is very efficient, but it makes things a bit complex, because one filesystem module must provide two different detection mechanisms. I'd like to vote for B. I like this simplicity. How about these procedures? This is a modified version of B: for each loaded filesystem module: try the filesystem with a specified partition/disk return if successful for each non-loaded filesystem module: load the filesystem module try the filesystem return if successful unload the filesystem module This is memory-efficient (unless the dynamic loader has memory leaks...), and this is slow only at the first attempt of the partition/disk. I prefer this to C, because I've seen the command "mount" in GNU/Linux not maintained all the time very well. I guess this is because the author of code for a filesystem may not use "mount -t auto ..." with the filesystem. This would happen even in GRUB, since you wouldn't notice that the autoload of your filesystem module is broken, if you preload it in core or explicitly load it manually or in a config file. Okuji