bug-grub
[Top][All Lists]
Advanced

[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



reply via email to

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