Re: automagic module loading - normal commands

[Marco Gerards]

Tomas Ebenlendr <address@hidden> writes:

> 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.

IMHO that is the best way to do this as well.  In an addition to this
you could have a look at the module that has the same name as the
command first.

Please don't forget that there are commands for normal mode and rescue
mode.  And a module can register multiple commands.

> 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.)

What do you mean?  You just load all modules once and if none of those
have the command display an error.

>> >     - 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
> sure.

I don't like hardcoding that much.  IMHO it should be possible to
throw another module in the directory and it just has to be loaded in
any case.

BTW, how do you deal with conflicts?  Or isn't that something that
should be considered to prevent complexity.

>> >      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.

Ok.

>
>> > +
>> > +  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
> case.)
> 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.)

I don't think you should assume "./" is valid in any case.  But what I
mean is that something like this is valid:

(/foo/bar)/baz

So a device with slashes should be valid.  That is something that we
should care of in general.  But that is not just for this patch...

> 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.

No problem.

Thanks,
Marco