[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automagic command loading

From: Tomas Ebenlendr
Subject: Re: Automagic command loading
Date: Thu, 30 Sep 2004 19:44:56 +0200
User-agent: Mutt/1.5.6i

> "Yoshinori K. Okuji" <address@hidden> writes:
> > On Wednesday 29 September 2004 23:38, Tomas Ebenlendr wrote:
> >> Disadvantage: current solution slowly reads the contens of directory.
> >> This is probably caused by opening files by /full/ path, where we
> >> principially have opened directory (and resolved path to it.).
> >
> > I think this is a critical problem. For example, if the user has a 
> > broken module which may crash GRUB, the user can easily break GRUB by 
> > trying a non-existent command.
> As far as I understood what Tomas said, the modules are loaded and
> only the new section is checked.  So it will not be initialized.
> > Also, if my understanding is correct, the list of modules is stored in a 
> > binary form. This means that the user cannot (easily) modify the list 
> > after building GRUB.
> Every module contains the list of commands it exports, AFAIK.  So the
> is no single big central list.
> > The advantage of autocmd.lst is that it makes customization much easier. 
> > Suppose that the user wants to add a new command and build his own 
> > module. Then, how to autoload this command?
> The new module will contain this specific section as well.

Yes, exactly. The section name is ".uinfo.norm_cmds" and command "command_name" 
stored there when NORMAL_COMMAND("command_name") occurs in file from

So typical use should be:

#ifdef GRUB_UTIL
module_name_init (...) {
    grub_register_command("command_name", ...)

    grub_register_command(NORMAL_COMMAND("command_name"), ...)

The first line with grub_register_command() does not affect module code.
So no NORMAL_COMMAND should be used. On the other hand, the second
line with grub_register_command() is code that occurs in module. So
using NORMAL_COMMAND ensures, that the "command_name" also occurs in the
special elf section.

                                 Tomas 'ebi' Ebenlendr
                                 PF 2004.74813635271

reply via email to

[Prev in Thread] Current Thread [Next in Thread]