[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for new user-ref manual
From: |
Thierry Laronde |
Subject: |
Re: Patch for new user-ref manual |
Date: |
Wed, 7 Feb 2001 14:17:36 +0100 |
User-agent: |
Mutt/1.2.5i |
On Wed, Feb 07, 2001 at 07:12:01PM +0900, OKUJI Yoshinori wrote:
> From: Thierry Laronde <address@hidden>
> Subject: Patch for new user-ref manual
> Date: Tue, 6 Feb 2001 16:19:05 +0100
>
> > Modifications : there were three groups of commands, remain two :
> > menu-specific (the ones used to describe how GRUB must handle the menu
> > interface), and general commands. So I have merged the whole listing of the
> > commands not menu-specific.
>
> I don't think that is a Right Thing. GRUB clearly has three groups:
> one that you may use only in the menu (not menu entries), one that you
> may use anywhere, and the other that you may use only in the
> command-line and menu entries. Their distinctions are important, since
> if you list commands usable only in menu entries and the command-line
> as general commands, the user could think that he/she might use them
> even out of menu entries.
The problem that I have is that, if I understand why the menu-specific are
menu-specific (they command the menu interface), I don't really understand
the limitation for others. I mean : the behavior is based on flags (builtins
ones), and these flags can be easily changed. Allowing, for example, `boot'
command to be launched outside of an entry could allow the automatic boot of
a single solution via the menu.lst considered more and more as a script.
Well the question is : is this limitation really necessary ?
To put the question further. In the future (not for 1.0), could it be possible
to use the area reserved for the name of the config file to put commands ? Or,
more precisely, could this area be a kind of command (style "sh /grub/menu.lst",
or "sh kernel (hd1,4)/<kernel> [parameters] ; boot", or even, '#!sh' to
distinguish script from a kind of grub executable) ? The config file of the
area being considered as the "init" of the grub kernel. Obviously, the cost
of a solution is the parsing of the "command line". But perhaps we could
think (not now) of a kind of compiled format for an entry, with no necessity
to parse, that is interpret a command line (this is on the todo list to try
to decrease the size of the core grub ; but this probably means to
distinguish the grub "kernel" from the "interpreter" used to parse the
config file).
--
Thierry LARONDE, Centre de Ressources Informatiques, Archamps - France
http://www.cri74.org
PingOO, serveur de com sur distribution GNU/Linux: http://www.pingoo.org