grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some design issues


From: Hollis Blanchard
Subject: Re: some design issues
Date: Tue, 15 Feb 2005 10:24:19 -0600

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





reply via email to

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