some design issues

some design issues

[Yoshinori K. Okuji]

I'd like to hear your opinions about some design-related issues.

Currently, GRUB 2 uses grub.cfg as the name of a default config file. I 
chose this, according to a private discussion between me and Jeremy 
Katz. He pointed out that the user did not find a config file if it was 
menu.lst, because he/she simply ran "locate grub". So the Red Hat 
version of GRUB legacy makes a symlink to menu.lst as grub.conf. I said 
that this name does not fit in 8.3 format. He agreed but he didn't want 
to discuss what name should be better.

I think the name "menu.lst" is really strange, so I don't like it. But I 
don't know if grub.cfg is nice. What do you think? I sometimes think 
that "grubrc" might be better (like "bashrc").

Next thing. I think it is a bad idea to make the variable for a menu 
global, because this is not compatible with having multiple nested 
menus. But some commands want to access information on the environment 
(such as current menu). I can think of two ways to address this issue:

1. Pass one more argument to each command. This argument would be a 
pointer to struct context, and contains a pointer to current menu, etc.

2. Provide global functions to access information. These functions would 
have to use global variables.

I don't know which is better.

Okuji

Re: some design issues

[Paul]

Hi Okuji et al:

> Currently, GRUB 2 uses grub.cfg as the name of a default config file.

I like grub.cnf.

Precedent is often a useful indicator... so I got to wondering what
others had done given similar circumstances...

I had a quick look through the /etc directory on my Debian (sarge)
system, counting the number of occurances of cnf/conf/rc files, using
the following command:
    find /etc/ | grep rc$

Quick summary of what I found:
  rc$: a fair few, including (parts of) X11, Gimp and OpenOffice
  cnf$: only Tex and MySQL on my system
  conf$: lots of stuff... but then again, I am running Linux.

Despite the fact files matching rc$ where quite common, I would steer
away from this choice, simply because rc files are associated with
user-level customization.  GRUB is not exactly user-level and thus is
more suited to a .conf filename.  Of course, the filename must comply
to 8.3 standard, so it seems only a choice of the best filename...

If it were my choice, and I needed an 8.3 filename, I would choose
grub.cnf.  If distributions want to symlink to grub.conf, no worries.
menu.lst is not obvious to me, and for this reason I am forever
double-checking I have the correct name with GRUB legacy.

> But I don't know if grub.cfg is nice.
It isn't.  But I think it is the best name given the requirements.

Cheers,
Paul.

Re: some design issues

[Hollis Blanchard]

On Feb 14, 2005, at 3:25 PM, Yoshinori K. Okuji wrote:
>
> Currently, GRUB 2 uses grub.cfg as the name of a default config file. I
> chose this, according to a private discussion between me and Jeremy
> Katz. He pointed out that the user did not find a config file if it was
> menu.lst, because he/she simply ran "locate grub". So the Red Hat
> version of GRUB legacy makes a symlink to menu.lst as grub.conf. I said
> that this name does not fit in 8.3 format. He agreed but he didn't want
> to discuss what name should be better.
>
> I think the name "menu.lst" is really strange, so I don't like it. But 
> I
> don't know if grub.cfg is nice. What do you think? I sometimes think
> that "grubrc" might be better (like "bashrc").

I like grub.cfg. The 8.3 format is very important to be able to keep it 
on a FAT filesystem (which I think will be critical for RS/6000 PowerPC 
support). "cfg" seems better to me than "cnf". I don't like "rc".

> Next thing. I think it is a bad idea to make the variable for a menu
> global, because this is not compatible with having multiple nested
> menus. But some commands want to access information on the environment
> (such as current menu). I can think of two ways to address this issue:
>
> 1. Pass one more argument to each command. This argument would be a
> pointer to struct context, and contains a pointer to current menu, etc.
>
> 2. Provide global functions to access information. These functions 
> would
> have to use global variables.

I haven't looked into the code in detail here, but I'd lean towards 2. 
Otherwise, *only* commands will be able to change the menu, and we may 
need other code to have that option in the future. (I have no specific 
ideas here, but just want to keep options open.)

-Hollis

Re: some design issues

[Yoshinori K. Okuji]

On Tuesday 15 February 2005 17:24, Hollis Blanchard wrote:
> I haven't looked into the code in detail here, but I'd lean towards
> 2. Otherwise, *only* commands will be able to change the menu, and we
> may need other code to have that option in the future. (I have no
> specific ideas here, but just want to keep options open.)

That sounds a good argument. I will follow this way.

Okuji

Re: some design issues

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> I think the name "menu.lst" is really strange, so I don't like it. But I 
> don't know if grub.cfg is nice. What do you think? I sometimes think 
> that "grubrc" might be better (like "bashrc").

I like grub.cfg.

> Next thing. I think it is a bad idea to make the variable for a menu 
> global, because this is not compatible with having multiple nested 
> menus. But some commands want to access information on the environment 
> (such as current menu). I can think of two ways to address this issue:
>
> 1. Pass one more argument to each command. This argument would be a 
> pointer to struct context, and contains a pointer to current menu, etc.
>
> 2. Provide global functions to access information. These functions would 
> have to use global variables.

With 2 you mean that the function accesses the current menu all the
time?  Is accessing another menu useful in some cases?

Thanks,

Re: some design issues

[Yoshinori K. Okuji]

On Tuesday 15 February 2005 20:41, Marco Gerards wrote:
> With 2 you mean that the function accesses the current menu all the
> time?  Is accessing another menu useful in some cases?

I don't understand the first question. As for the second question, I 
have no idea.

Okuji

Re: some design issues

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Tuesday 15 February 2005 20:41, Marco Gerards wrote:
>> With 2 you mean that the function accesses the current menu all the
>> time?  Is accessing another menu useful in some cases?
>
> I don't understand the first question. As for the second question, I 
> have no idea.

What I meant is that when not passing a pointer for the context the
functions can only access the current menu, right?

--
Marco

Re: some design issues

[Yoshinori K. Okuji]

On Wednesday 16 February 2005 19:05, Marco Gerards wrote:
> What I meant is that when not passing a pointer for the context the
> functions can only access the current menu, right?

I don't think so. It depends on an implementation. For example, it is 
possible to make a linked list of menus... I don't know how useful this 
can be, though.

Okuji

Re: some design issues

[Vincent Pelletier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yoshinori K. Okuji wrote:
| 1. Pass one more argument to each command. This argument would be a
| pointer to struct context, and contains a pointer to current menu, etc.

Isn't it already present ?
There is a "nested" variable passed to menu main function, that should
do the trick (leaving a menu which is nested would give back  the
control to the calling menu, which would redraw itself).

Vincent Pelletier
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCElqWFEQoKRQyjtURAj5tAJ4vbVN/59NQcT3n1o84a+Td8lziagCdEhLY
zQKMUM0jNWFDCWzLA2lf4/M=
=K5m+
-----END PGP SIGNATURE-----

Re: some design issues

[Yoshinori K. Okuji]

On Tuesday 15 February 2005 21:24, Vincent Pelletier wrote:
> Isn't it already present ?

No.

> There is a "nested" variable passed to menu main function, that
> should do the trick (leaving a menu which is nested would give back 
> the control to the calling menu, which would redraw itself).

It is a different thing. The question is, for example, how to add a new 
menu entry into current menu. Suppose this command:

entry "foo" {
}

The command "entry" should be an ordinary command. I don't want to make 
it special like "title" in GRUB Legacy. Then, this command must be able 
to access a menu variable. So, one way is to define the function like 
this:

grub_err_t 
grub_cmd_entry (struct grub_arg_list *state, int argc, char **args, 
grub_context_t context)
{
  grub_menu_add_entry (context->menu, ...);
  ...
}

Another way is:

grub_err_t 
grub_cmd_entry (struct grub_arg_list *state, int argc, char **args)
{
  grub_context_t context = grub_get_context ();

  grub_menu_add_entry (context->menu, ...);
  ...
}

Okuji

Re: some design issues

[Serbinenko Vladimir]

Yoshinori K. Okuji wrote:

>On Tuesday 15 February 2005 21:24, Vincent Pelletier wrote:
>  
>
>>Isn't it already present ?
>>    
>>
>
>No.
>
>  
>
>>There is a "nested" variable passed to menu main function, that
>>should do the trick (leaving a menu which is nested would give back 
>>the control to the calling menu, which would redraw itself).
>>    
>>
>
>It is a different thing. The question is, for example, how to add a new 
>menu entry into current menu. Suppose this command:
>
>entry "foo" {
>}
>
>The command "entry" should be an ordinary command. I don't want to make 
>it special like "title" in GRUB Legacy. Then, this command must be able 
>to access a menu variable. So, one way is to define the function like 
>this:
>
>grub_err_t 
>grub_cmd_entry (struct grub_arg_list *state, int argc, char **args, 
>grub_context_t context)
>{
>  grub_menu_add_entry (context->menu, ...);
>  ...
>}
>
>Another way is:
>
>grub_err_t 
>grub_cmd_entry (struct grub_arg_list *state, int argc, char **args)
>{
>  grub_context_t context = grub_get_context ();
>
>  grub_menu_add_entry (context->menu, ...);
>  ...
>}
>
>  
>
In my scripting engine entry is parsed the same way that function. Only 
difference is where contents stored but it's not written as a normal 
function because it changes a bit the way the input parsed (no 
expanding, ...) What do you think about it?

>Okuji
>
>
>  
>
>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>

Re: some design issues

[Yoshinori K. Okuji]

On Wednesday 16 February 2005 17:01, Serbinenko Vladimir wrote:
> In my scripting engine entry is parsed the same way that function.
> Only difference is where contents stored but it's not written as a
> normal function because it changes a bit the way the input parsed (no
> expanding, ...) What do you think about it?

You can treat commands between braces as a group. In bash, a function is 
defined in the following way:

foo() {
 ...
}

Or:

function foo {
  ...
}

In both cases, the contents enclosed with braces are not evaluated but 
defined as the body of the function `foo'.

For me, the command `entry' is a kind of shell function. The difference 
between an entry and a function is that an entry is a part of a menu,  
while a function is a command. In other words, an entry is an anonymous 
function which is assigned to a slot in a menu.

So I think a clean way is to pass such a group as a single argument. For 
example, if the user specifies this:

entry "foo" { kernel /boot/vmlinuz; initrd /boot/initrd }

your parser would invoke grub_cmd_entry with the arguments "foo" and 
"kernel /boot/vmlinuz; initrd /boot/initd".

If the user specifies this:

function foo { kernel /boot/vmlinuz; initrd /boot/initrd }

it would invoke grub_cmd_function with the argument "foo" and 
"kernel /boot/vmlinuz; initrd /boot/initd".

This looks consistent to me.

Okuji

Re: some design issues

[Serbinenko Vladimir]

Yes this is exactly what I wrote what I spoke about is that when parser 
recognizes a function header it creates a list instead of executing. 
Entry command can not be a normal function because if you write
entry "foo" { for ((i = 0; i < 9; i++)); do echo $i; done }
Normal executing would expand $i before running command that will break 
the function
That's why I parse function by the same engine that loops and conditions.
entry and function are parsed the *same* way only difference is which 
variable engine uses to store it (menu or function list)

Yoshinori K. Okuji wrote:

>On Wednesday 16 February 2005 17:01, Serbinenko Vladimir wrote:
>  
>
>>In my scripting engine entry is parsed the same way that function.
>>Only difference is where contents stored but it's not written as a
>>normal function because it changes a bit the way the input parsed (no
>>expanding, ...) What do you think about it?
>>    
>>
>
>You can treat commands between braces as a group. In bash, a function is 
>defined in the following way:
>
>foo() {
> ...
>}
>
>Or:
>
>function foo {
>  ...
>}
>
>In both cases, the contents enclosed with braces are not evaluated but 
>defined as the body of the function `foo'.
>
>For me, the command `entry' is a kind of shell function. The difference 
>between an entry and a function is that an entry is a part of a menu,  
>while a function is a command. In other words, an entry is an anonymous 
>function which is assigned to a slot in a menu.
>
>So I think a clean way is to pass such a group as a single argument. For 
>example, if the user specifies this:
>
>entry "foo" { kernel /boot/vmlinuz; initrd /boot/initrd }
>
>your parser would invoke grub_cmd_entry with the arguments "foo" and 
>"kernel /boot/vmlinuz; initrd /boot/initd".
>
>If the user specifies this:
>
>function foo { kernel /boot/vmlinuz; initrd /boot/initrd }
>
>it would invoke grub_cmd_function with the argument "foo" and 
>"kernel /boot/vmlinuz; initrd /boot/initd".
>
>This looks consistent to me.
>
>Okuji
>
>  
>

>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>