Re: automagic module loading - normal commands

[Tomas Ebenlendr]

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

There will be no autoloading support for rescue mode commands. Rescue
mode should be totally under control of user, and not loading harmful
module can be important.

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

Yes but I will not cache the error. So next time the command is
requested, I again read all modules and display error, that command was
not found.

> >> >     - 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.
> 
Yes, but I'm talking about autocmd patch. If there should be
autocmd.mod, or the automagic module loading should be hardcoded in
normal.mod (such that user has option only to turn it off), as it is
done in my patch.

> BTW, how do you deal with conflicts?  Or isn't that something that
> should be considered to prevent complexity.
> 
Hmm, I think, that there shouldn't be 2 commands of same name. Otherwise
user must load the correct module first. The second module will be
probably unusable then (because there will be no way to run the
conflicting command).

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

But here I know the path is 'absolute' if it contains slash somwhere, no
matter if it is in device name, or path. If there is no slash at all, It
is considered here as if $prefix/the_file_name was entered.
I only suggested that there may be shortcut for ${prefix}/relative_path
in form ./relative_path, but maybe it is only nonsencial overloading of
variable prefix.

-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.72914725005