Re: Automagic command loading

["Yoshinori K. Okuji" <okuji@enbug.org>]

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