[Top][All Lists]

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

Re: automagic module loading - normal commands

From: Tomas Ebenlendr
Subject: Re: automagic module loading - normal commands
Date: Thu, 23 Sep 2004 00:53:46 +0200
User-agent: Mutt/1.5.6i

> Tomas Ebenlendr <address@hidden> writes:
> > I want to do better my autocmd patch. Now it reads file autocmd.lst in
> > root directory. (this can be changed via variable 'autocmd'). I have
> > following questions:
> >     - Do we want to have special file like autocmd.lst? Or
> >       to 'probe' all modules: read a module, and read from some special
> >       elf section supported commands? Or both? (Or other way to decide
> >       which module to load?)
> I think a autocmd.lst file is not that nice.  In that case you would
> have to add every module manually to it.
> Here are some comments.  I did not read the patch in detail so I
> missed a lot I wanted to ask you about, I guess.
> Did you make sure commands that did not get autoloaded won't we
> automatically removed?  Or doesn't that ever happen?

no autocmd.lst:
I can then write same information in module directly, as there is
written the module name and its dependencies. So I will not run
initialization of unwanted (and possibly harmfull) module. All
not-loaded modules will then be read and seeked for that information. If
specified command will be found, module gets loaded.

commands that not get autoload (and aren't registered):
It is misconfiguration of grub, when such command will be tried
frequently. So I think, we can probe such commands forever. (This allows
to copy module while grub is running, e.g. on network filesystem to
proper directory and then try the command once more.)

> >     - Do we want to have automatic module loading hardcoded? Or should
> >       there be a generic interface, so some other module will drive
> >       automatic module loading?
> I don't understand what you mean.
If somebody wants to implement different way of guessing module from
command name, he should hack normal.mod in first case, and create his
own module in second. The second case is probably useless, but I'm not

> >       Or from *.c (by preprocessing and greping, such as symbols
> >       are from *.h)
> >       Or else way?
> Perhaps by grepping for register_command or so?  But as I said IMHO
> autocmd.lst is not the right thing to do.
Specific section in elf header will probably need the same input. As I
said, I don't want to initialize module, because it can be harmful, or
time-consuming, so I need to dig (or read from *.rmk) the information
about commands, that current module provides.

> > +
> > +  p = grub_strchr (env->value, '/');
> Is this to look up filenames / devices?  In that case see the patch I
> applied today and the discussion about slashes in device names.   In
> that case you should do the same to make sure it works on all machines.

No, if there is no slash, the file is considered to live in directory
in variable 'prefix'. I think this could be changed to have './foo/baz'
notation for this in general. (for every file lookup, not only for this
If there will be no autocmd.lst, there will be no such lookup. (I
probably change meaning of autocmd variable, so user can turn on and off
automagic module loading.)

Sory for GCS-errors. As you see, this patch i wrote in june. I re-post
it here because discusion about this died, and I had no time.
                                 Tomas 'ebi' Ebenlendr
                                 PF 2004.72685153562

reply via email to

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