From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1CDP8N-0004jx-B4 for mharc-grub-devel@gnu.org; Fri, 01 Oct 2004 11:15:47 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CDP8L-0004jA-0r for grub-devel@gnu.org; Fri, 01 Oct 2004 11:15:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CDP8I-0004hp-Gh for grub-devel@gnu.org; Fri, 01 Oct 2004 11:15:42 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CDP8I-0004hY-A6 for grub-devel@gnu.org; Fri, 01 Oct 2004 11:15:42 -0400 Received: from [212.43.237.68] (helo=kotoba.storever.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CDP1d-00052l-PL for grub-devel@gnu.org; Fri, 01 Oct 2004 11:08:49 -0400 Received: from localhost (localhost [127.0.0.1]) by kotoba.storever.com (Postfix) with ESMTP id A3325F57736E for ; Fri, 1 Oct 2004 17:08:47 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Fri, 1 Oct 2004 17:09:03 +0200 User-Agent: KMail/1.6.1 References: <20040928190544.GA24852@artax.karlin.mff.cuni.cz> <200409301533.28151.okuji@enbug.org> <871xgjg5ll.fsf@marco.marco-g.com> In-Reply-To: <871xgjg5ll.fsf@marco.marco-g.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410011709.03394.okuji@enbug.org> Subject: Re: Automagic command loading 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: Fri, 01 Oct 2004 15:15:45 -0000 My intuition is that this is not a good solution. So I think of another example. The user does not like the behavior of, say, ls. So he writes his own module for an exhanced version of ls. Then, which does GRUB load? I do not like this undeterministic behavior. You may think that the user can simply remove the original module and add his own. This is true, but I don't think this is a clean way. One more example. Suppose that GRUB supports 100 commands and 100 filesystems. Probably the overhead of loading all modules would be negligible on Pentium4, but isn't it significant on 486? We should not forget that some people still use very old computers. I don't see any serious disadvantage in autocmd.lst. Generating this file is as easy as embedding command names in modules. Editing this file is not difficult at all for users who can write their own modules. Generally speaking, text-based approaches are better than binary-based approaches. For example, if the user wants to know what modules contains a given command, he can just grep autocmd.lst instead of reading the source code or using readelf. BTW, I think it would be useful to investigate why loading all modules takes 5 seconds on bochs. Even on bochs, I feel this is too much. There might be a bug in the disk cache system. Tomas, could you look at the cache efficiency when loading all modules? You can get this information by the function grub_disk_cache_get_performance. To enable this function, you need to change kern/disk.c, because I disable this by #if 0 ... #endif. Okuji