Scripts and menus
IMHO. Current system with title command is ugly because:
-grub.cfg requires the separate parser. IMHO it should be
parsed the same way as user input.
-Even when scripting support will be ready it's impossible
to create multiple menus of the same kind by just a loop (like
for x in /boot/vmlinuz-*;
do
menuitem name="linux-$x" title="Linux with kernel $x"
linux $x [....]
endmenuitem;
done;)
- if in future menu entrys will have more parameters (e.g: name, keyboard shortcut) how could we specify them?
As arisen in discussion about serial console multiple menus could be useful. I propose to split munu.c in general (e.g: run_entry) and menu-specific (like run_menu) and then make multiple menu support like done with terminals. Then we could add other menus: like lilo menu (additional parameters could be stored in variable: then boot function could also look at this variable for parameters (of course parameters from unauthorized users will be ignored)), vesa menu
(and 3rd party programmers could write vesa menus then it would be like skin support), x-menu over ssh/network, ...
IMHO grub2 needs scripting support to be more powerful I propose to use bison translating commands in the structures like:
struct command
{
enum type {SCRIPT_CMD_NORMAL, SCRIPT_CMD_IF, [...]}; /* type of
command*/
enum link {SCRIPT_LINK_NORMAL, SCRIPT_LINK_AND, [...]}; /* Was there
a &&, ||, ... before command?*/
union
{
char *command;
struct command *if_jump; /* Bison could translate the condition
as preceding command*/
[...]
}
};then menu-entrys could be
menuentry name=<name> title=<title> [key-shortcut=<..>] [picture=<...>]
<....>
endmenuentry
I'm ready to make the work of menu-splitting, lilo-menu and scripting
What do you think about it?
Vladimir
The problem with your idea is that it at least appears to be too Linux-centric, and forgets entirely about other operating systems, invalidating the "unified" part of the GRUB name. And I get fed up when on my machine which as FC3 has one of the OSes (along with NetBSD and several others), up2date ignores the fact that FC3 **is not** the default.
BTW...If 1.9 is supposed to be indicating that we are nearing a 2.0 release, I don't think that now would be the time for such a major change. After nearly 30 years of programming, one of the problems I have seen in too many Open Source projects is that a release cycle is supposedly started, but...
1) No release branch is started in the source repository.
or
2) Major, non-critical changes are committed to the release branch, which in turn delay the release or make it unstable.
In short...if you have the features in which you have decided upon for a release, branch, start testing, and the only thing which goes on the branch are fixes for problems or pullups related to security. All other work stays on the mainline branch for the next major release.
Just my opinion...
- Doug
Quoted 60 lines · Vladimir Serbinenko
IMHO. Current system with title command is ugly because:
-grub.cfg requires the separate parser. IMHO it should be
parsed the same way as user input.
-Even when scripting support will be ready it's impossible
to create multiple menus of the same kind by just a loop (likefor x in /boot/vmlinuz-*; do menuitem name="linux-$x" title="Linux with kernel $x" linux $x [....] endmenuitem; done;)
- if in future menu entrys will have more parameters (e.g: name, keyboard shortcut) how could we specify them?As arisen in discussion about serial console multiple menus could be useful. I propose to split
munu.cin general (e.g:run_entry) and menu-specific (likerun_menu) and then make multiple menu support like done with terminals. Then we could add other menus: like lilo menu (additional parameters could be stored in variable: then boot function could also look at this variable for parameters (of course parameters from unauthorized users will be ignored)), vesa menu
(and 3rd party programmers could write vesa menus then it would be like skin support), x-menu over ssh/network, ...IMHO grub2 needs scripting support to be more powerful I propose to use bison translating commands in the structures like:
struct command{ enum type {SCRIPT_CMD_NORMAL, SCRIPT_CMD_IF, [...]}; /* type of command*/ enum link {SCRIPT_LINK_NORMAL, SCRIPT_LINK_AND, [...]}; /* Was there a &&, ||, ... before command?*/ union { char *command; struct command *if_jump; /* Bison could translate the condition as preceding command*/ [...] } };then menu-entrys could be
menuentry name=<name> title=<title> [key-shortcut=<..>] [picture=<...>]<....>endmenuentry
I'm ready to make the work of menu-splitting, lilo-menu and scripting
What do you think about it?
Vladimir
_______________________________________________
Grub-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel
Signature · 4 lines
Douglas Wade Needham - KA8ZRT UN*X Consultant & UW/BSD kernel programmer
Email: cinnion @ ka8zrt . com http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own. Since I don't want them, why
should my employer, or anybody else for that matter! Quoted 8 lines · Douglas Wade Needham
The problem with your idea is that it at least appears to be too Linux-centric, and forgets entirely about other operating systems, invalidating the "unified" part of the GRUB name. And I get fed up when on my machine which as FC3 has one of the OSes (along with NetBSD and several others), up2date ignores the fact that FC3 **is not** the default.
Why linux centric? Scripting is an universal thing. If you speak about
for x in /boot/vmlinuz-*; [...]
it was just an example.
"Menu modules" are also general thing. Lilo-like menu was also an example but it could also be used with other OS that linux (other loaders can also check for additional commands).
About menu-entry syntax - I see nothing linux-centric
Or don't I understand something?
Vladimir
Quoted 1 line · Vladimir Serbinenko
IMHO. Current system with title command is ugly because:
I have already proposed my idea of making each entry a function before. First, please describe why you don't think this is not enough.
Okuji
Quoted 5 lines · Douglas Wade Needham
BTW...If 1.9 is supposed to be indicating that we are nearing a 2.0 release, I don't think that now would be the time for such a major change. After nearly 30 years of programming, one of the problems I have seen in too many Open Source projects is that a release cycle is supposedly started, but...
Do not care about the version number. For now, GRUB 2 is at an alpha stage. Rather, you must not stop thinking how to improve GRUB 2. So I appreciate that Vladimir is thinking various possibilities.
Possibly, we will have to begin stabilizing GRUB 2 in near future, maybe in 6 months. Once we decide this, we should not make any (user-visible) incompatible change, because the requirement for a boot loader is more severe than other software. So, reversely, we should consider what we can change as much as possible at this moment. If we miss this occasion, the next chance is GRUB 3.
Okuji
Quoted 5 lines · Yoshinori K. Okuji
I have already proposed my idea of making each entry a function before. First, please describe why you don't think this is not enough.
It's only a question of syntax so it's ok but IMHO 2 points are important:
1) It must be possible to set additional attributes to a menu entry
2) It must be possible to create functions that are *not* the menu
entries
Vladimir
Quoted 2 lines · Vladimir Serbinenko
It's only a question of syntax so it's ok but IMHO 2 points are important:
1) It must be possible to set additional attributes to a menu entry
I'd like to use options for these. Like this:
entry --label="gnu" --key="g" "GNU 0.3" {
root=(hd0,0)
multiboot /gnumach
module /serverboot
}
Quoted 2 lines
2) It must be possible to create functions that are *not* the menu
entries
They should be the same as Bash:
function load_modules {
module /boot/module1
module /boot/module2
}
entry "My OS version 1" {
multiboot /boot/kernel-1
load_modules
}
entry "My OS version 2" {
multiboot /boot/kernel-2
load_modules
}
Okuji
Ok. At this moment I have one thing to do that will be approximately finished
on Thursday and then I'll do it (on next Monday I suppose my assignment will be finished)
Is it ok to create bison parser that will parse command by command and create a pseudocode at output that can be easily executed?
Quoted 50 lines · Yoshinori K. Okuji
Quoted 4 lines · Vladimir Serbinenko
It's only a question of syntax so it's ok but IMHO 2 points are important:
1) It must be possible to set additional attributes to a menu entryI'd like to use options for these. Like this:
entry --label="gnu" --key="g" "GNU 0.3" {
root=(hd0,0)
multiboot /gnumach
module /serverboot
}Quoted 4 lines
2) It must be possible to create functions that are *not* the menu
entriesThey should be the same as Bash:
function
load_modules{
module/boot/module1
module/boot/module2
}entry "My OS version 1" {
multiboot/boot/kernel-1
load_modules
}entry "My OS version 2" {
multiboot/boot/kernel-2
load_modules
}Okuji
_______________________________________________
Grub-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel
Quoted 11 lines · Yoshinori K. Okuji
Quoted 5 lines · Douglas Wade Needham
BTW...If 1.9 is supposed to be indicating that we are nearing a 2.0 release, I don't think that now would be the time for such a major change. After nearly 30 years of programming, one of the problems I have seen in too many Open Source projects is that a release cycle is supposedly started, but...
Do not care about the version number. For now, GRUB 2 is at an alpha stage. Rather, you must not stop thinking how to improve GRUB 2. So I appreciate that Vladimir is thinking various possibilities.
Quoted 6 lines
Possibly, we will have to begin stabilizing GRUB 2 in near future, maybe in 6 months. Once we decide this, we should not make any (user-visible) incompatible change, because the requirement for a boot loader is more severe than other software. So, reversely, we should consider what we can change as much as possible at this moment. If we miss this occasion, the next chance is GRUB 3.
I agree that we should not continue to think about improvements, etc. However, if we are talking alpha/beta/rc stages, then we should be talking about a release branch, into which we only put controlled changes. Otherwise, we will not get the stability during testing, and the end result will likely be far from what we want, either in time or in quality.
- Doug
Quoted 6 lines · Douglas Wade Needham
I agree that we should not continue to think about improvements, etc. However, if we are talking alpha/beta/rc stages, then we should be talking about a release branch, into which we only put controlled changes. Otherwise, we will not get the stability during testing, and the end result will likely be far from what we want, either in time or in quality.
Don't worry. We do not need to make a stable version for a while. Now is too early to talk about branching in GRUB 2.
Okuji
[DISCUSSION] Grub2 Improvements
In reply to Douglas Wade Needham-----Original Message-----
Quoted 27 lines
Date: Mon, 15 Aug 2005 00:54:11 +0200
Subject: Re: [DISCUSSION] Scripts and menus
From: Douglas Wade Needham <[email protected]>
To: The development of GRUB 2 <[email protected]>Quoted 13 lines · Yoshinori K. Okuji
Quoted 6 lines · Douglas Wade Needham
BTW...If 1.9 is supposed to be indicating that we are nearing a 2.0 release, I don't think that now would be the time for such a major change. After nearly 30 years of programming, one of the problems I have seen in too many Open Source projects is that a release cycle is supposedly started, but...
Do not care about the version number. For now, GRUB 2 is at an alpha stage.
Rather, you must not stop thinking how to improve GRUB 2. So I appreciate that Vladimir is thinking various possibilities.Quoted 7 lines
Possibly, we will have to begin stabilizing GRUB 2 in near future, maybe in 6 months. Once we decide this, we should not make any (user-visible) incompatible change, because the requirement for a boot loader is more severe than other software. So, reversely, we should consider what we can change as much as possible at this moment. If we miss this occasion, the next chance is GRUB 3.
Quoted 6 lines
I agree that we should not continue to think about improvements, etc. However, if we are talking alpha/beta/rc stages, then we should be talking about a release branch, into which we only put controlled changes. Otherwise, we will not get the stability during testing, and the end result will likely be far from what we want, either in time or in quality.
I would agree with this. We should have a stable basis on which we can improve grub2. There are so many improvments, e.g. vesafb module and many others, and later a graphical menu, but we dont have a structure for a menu entry (or a stable). Other modules/improvement uses this basis and when this basis changes, parts of grub2/modules must be rewritten to fit to the basis. We should create a list of improvments (all the improvments which occurs in the list) and set priorities. We should cralify which improvements apear in the next release and which not, ...
BTW I have successfully compiled grub2 on FreeBSD 5.3-RELEASE, but havent tested it completely.
Quoted 8 lines
- Doug
_______________________________________________
Grub-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [DISCUSSION] Grub2 Improvements
Quoted 9 lines · On Monday 15 August 2005 09:27, [email protected] wrote:
I would agree with this. We should have a stable basis on which we can improve grub2. There are so many improvments, e.g. vesafb module and many others, and later a graphical menu, but we dont have a structure for a menu entry (or a stable). Other modules/improvement uses this basis and when this basis changes, parts of grub2/modules must be rewritten to fit to the basis. We should create a list of improvments (all the improvments which occurs in the list) and set priorities. We should cralify which improvements apear in the next release and which not, ...
Do not use "we should", when "we" do not include yourself.
I do not like your idea. I have already said that we do not need branching at the moment. If you need stability, use GRUB Legacy. That's it.
Okuji
Vladimir Serbinenko <[email protected]> writes:
Hi Vladimir,
Quoted 7 lines
Ok. At this moment I have one thing to do that will be approximately finished
on Thursday and then I'll do it (on next Monday I suppose my assignment will be finished)Is it ok to create bison parser that will parse command by command and create a pseudocode at output that can be easily executed?
It would be nice if you could post your flex/bison code first. In that case we can discuss the syntax and how to fill in the implementation before continuing. I think being able to verify the input before getting output is a big enough task to start with.
Thanks,
Marco
PATCH 1/1 Scripting engine
I wrote the preciew version of scripting engine. I'll add some comments soonly.
Parser parses everytime one command because the commands could be entered from
commandline. Bison converts in kind of pseudocode. Arithmethic support will be done
by separate parser because arithmetic parse is very different form bash one. Patch is attached. The next thing I'll do is adding entry handling and changing menu
parser to the call of scripting engine. It would be good if then it could be incorporated
to CVS because it would be easy to developpe and debug.
Vladimir
grub2_4/conf/i386-pc.mk renamed from grub2_3/conf/i386-pc.mk +35 -8
@@ -686,11 +686,11 @@ partmap/amiga.c partmap/apple.c partmap/pc.c partmap/sun.c \ util/console.c util/grub-emu.c util/misc.c \ util/i386/pc/biosdisk.c util/i386/pc/getroot.c \ - util/i386/pc/misc.c -CLEANFILES += grub-emu grub_emu-commands_boot.o grub_emu-commands_cat.o grub_emu-commands_hexcat.o grub_emu-commands_cmp.o grub_emu-commands_configfile.o grub_emu-commands_default.o grub_emu-commands_help.o grub_emu-commands_terminal.o grub_emu-commands_ls.o grub_emu-commands_timeout.o grub_emu-commands_i386_pc_halt.o grub_emu-commands_i386_pc_reboot.o grub_emu-disk_loopback.o grub_emu-fs_ext2.o grub_emu-fs_fat.o grub_emu-fs_fshelp.o grub_emu-fs_hfs.o grub_emu-fs_iso9660.o grub_emu-fs_jfs.o grub_emu-fs_minix.o grub_emu-fs_ufs.o grub_emu-kern_device.o grub_emu-kern_disk.o grub_emu-kern_dl.o grub_emu-kern_env.o grub_emu-kern_err.o grub_emu-kern_file.o grub_emu-kern_fs.o grub_emu-kern_loader.o grub_emu-kern_main.o grub_emu-kern_misc.o grub_emu-kern_partition.o grub_emu-kern_rescue.o grub_emu-kern_term.o grub_emu-normal_arg.o grub_emu-normal_cmdline.o grub_emu-normal_command.o grub_emu-normal_context.o grub_emu-normal_main.o grub_emu-normal_menu.o grub_emu-normal_menu_entry.o grub_emu-partmap_amiga.o grub_emu-partmap_apple.o grub_emu-partmap_pc.o grub_emu-partmap_sun.o grub_emu-util_console.o grub_emu-util_grub_emu.o grub_emu-util_misc.o grub_emu-util_i386_pc_biosdisk.o grub_emu-util_i386_pc_getroot.o grub_emu-util_i386_pc_misc.o -MOSTLYCLEANFILES += grub_emu-commands_boot.d grub_emu-commands_cat.d grub_emu-commands_hexcat.d grub_emu-commands_cmp.d grub_emu-commands_configfile.d grub_emu-commands_default.d grub_emu-commands_help.d grub_emu-commands_terminal.d grub_emu-commands_ls.d grub_emu-commands_timeout.d grub_emu-commands_i386_pc_halt.d grub_emu-commands_i386_pc_reboot.d grub_emu-disk_loopback.d grub_emu-fs_ext2.d grub_emu-fs_fat.d grub_emu-fs_fshelp.d grub_emu-fs_hfs.d grub_emu-fs_iso9660.d grub_emu-fs_jfs.d grub_emu-fs_minix.d grub_emu-fs_ufs.d grub_emu-kern_device.d grub_emu-kern_disk.d grub_emu-kern_dl.d grub_emu-kern_env.d grub_emu-kern_err.d grub_emu-kern_file.d grub_emu-kern_fs.d grub_emu-kern_loader.d grub_emu-kern_main.d grub_emu-kern_misc.d grub_emu-kern_partition.d grub_emu-kern_rescue.d grub_emu-kern_term.d grub_emu-normal_arg.d grub_emu-normal_cmdline.d grub_emu-normal_command.d grub_emu-normal_context.d grub_emu-normal_main.d grub_emu-normal_menu.d grub_emu-normal_menu_entry.d grub_emu-partmap_amiga.d grub_emu-partmap_apple.d grub_emu-partmap_pc.d grub_emu-partmap_sun.d grub_emu-util_console.d grub_emu-util_grub_emu.d grub_emu-util_misc.d grub_emu-util_i386_pc_biosdisk.d grub_emu-util_i386_pc_getroot.d grub_emu-util_i386_pc_misc.d + util/i386/pc/misc.c normal/parser.c +CLEANFILES += grub-emu grub_emu-commands_boot.o grub_emu-commands_cat.o grub_emu-commands_hexcat.o grub_emu-commands_cmp.o grub_emu-commands_configfile.o grub_emu-commands_default.o grub_emu-commands_help.o grub_emu-commands_terminal.o grub_emu-commands_ls.o grub_emu-commands_timeout.o grub_emu-commands_i386_pc_halt.o grub_emu-commands_i386_pc_reboot.o grub_emu-disk_loopback.o grub_emu-fs_ext2.o grub_emu-fs_fat.o grub_emu-fs_fshelp.o grub_emu-fs_hfs.o grub_emu-fs_iso9660.o grub_emu-fs_jfs.o grub_emu-fs_minix.o grub_emu-fs_ufs.o grub_emu-kern_device.o grub_emu-kern_disk.o grub_emu-kern_dl.o grub_emu-kern_env.o grub_emu-kern_err.o grub_emu-kern_file.o grub_emu-kern_fs.o grub_emu-kern_loader.o grub_emu-kern_main.o grub_emu-kern_misc.o grub_emu-kern_partition.o grub_emu-kern_rescue.o grub_emu-kern_term.o grub_emu-normal_arg.o grub_emu-normal_cmdline.o grub_emu-normal_command.o grub_emu-normal_context.o grub_emu-normal_main.o grub_emu-normal_menu.o grub_emu-normal_menu_entry.o grub_emu-partmap_amiga.o grub_emu-partmap_apple.o grub_emu-partmap_pc.o grub_emu-partmap_sun.o grub_emu-util_console.o grub_emu-util_grub_emu.o grub_emu-util_misc.o grub_emu-util_i386_pc_biosdisk.o grub_emu-util_i386_pc_getroot.o grub_emu-util_i386_pc_misc.o grub_emu-normal_parser.o +MOSTLYCLEANFILES += grub_emu-commands_boot.d grub_emu-commands_cat.d grub_emu-commands_hexcat.d grub_emu-commands_cmp.d grub_emu-commands_configfile.d grub_emu-commands_default.d grub_emu-commands_help.d grub_emu-commands_terminal.d grub_emu-commands_ls.d grub_emu-commands_timeout.d grub_emu-commands_i386_pc_halt.d grub_emu-commands_i386_pc_reboot.d grub_emu-disk_loopback.d grub_emu-fs_ext2.d grub_emu-fs_fat.d grub_emu-fs_fshelp.d grub_emu-fs_hfs.d grub_emu-fs_iso9660.d grub_emu-fs_jfs.d grub_emu-fs_minix.d grub_emu-fs_ufs.d grub_emu-kern_device.d grub_emu-kern_disk.d grub_emu-kern_dl.d grub_emu-kern_env.d grub_emu-kern_err.d grub_emu-kern_file.d grub_emu-kern_fs.d grub_emu-kern_loader.d grub_emu-kern_main.d grub_emu-kern_misc.d grub_emu-kern_partition.d grub_emu-kern_rescue.d grub_emu-kern_term.d grub_emu-normal_arg.d grub_emu-normal_cmdline.d grub_emu-normal_command.d grub_emu-normal_context.d grub_emu-normal_main.d grub_emu-normal_menu.d grub_emu-normal_menu_entry.d grub_emu-partmap_amiga.d grub_emu-partmap_apple.d grub_emu-partmap_pc.d grub_emu-partmap_sun.d grub_emu-util_console.d grub_emu-util_grub_emu.d grub_emu-util_misc.d grub_emu-util_i386_pc_biosdisk.d grub_emu-util_i386_pc_getroot.d grub_emu-util_i386_pc_misc.d grub_emu-normal_parser.d -grub-emu: grub_emu-commands_boot.o grub_emu-commands_cat.o grub_emu-commands_hexcat.o grub_emu-commands_cmp.o grub_emu-commands_configfile.o grub_emu-commands_default.o grub_emu-commands_help.o grub_emu-commands_terminal.o grub_emu-commands_ls.o grub_emu-commands_timeout.o grub_emu-commands_i386_pc_halt.o grub_emu-commands_i386_pc_reboot.o grub_emu-disk_loopback.o grub_emu-fs_ext2.o grub_emu-fs_fat.o grub_emu-fs_fshelp.o grub_emu-fs_hfs.o grub_emu-fs_iso9660.o grub_emu-fs_jfs.o grub_emu-fs_minix.o grub_emu-fs_ufs.o grub_emu-kern_device.o grub_emu-kern_disk.o grub_emu-kern_dl.o grub_emu-kern_env.o grub_emu-kern_err.o grub_emu-kern_file.o grub_emu-kern_fs.o grub_emu-kern_loader.o grub_emu-kern_main.o grub_emu-kern_misc.o grub_emu-kern_partition.o grub_emu-kern_rescue.o grub_emu-kern_term.o grub_emu-normal_arg.o grub_emu-normal_cmdline.o grub_emu-normal_command.o grub_emu-normal_context.o grub_emu-normal_main.o grub_emu-normal_menu.o grub_emu-normal_menu_entry.o grub_emu-partmap_amiga.o grub_emu-partmap_apple.o grub_emu-partmap_pc.o grub_emu-partmap_sun.o grub_emu-util_console.o grub_emu-util_grub_emu.o grub_emu-util_misc.o grub_emu-util_i386_pc_biosdisk.o grub_emu-util_i386_pc_getroot.o grub_emu-util_i386_pc_misc.o +grub-emu: grub_emu-commands_boot.o grub_emu-commands_cat.o grub_emu-commands_hexcat.o grub_emu-commands_cmp.o grub_emu-commands_configfile.o grub_emu-commands_default.o grub_emu-commands_help.o grub_emu-commands_terminal.o grub_emu-commands_ls.o grub_emu-commands_timeout.o grub_emu-commands_i386_pc_halt.o grub_emu-commands_i386_pc_reboot.o grub_emu-disk_loopback.o grub_emu-fs_ext2.o grub_emu-fs_fat.o grub_emu-fs_fshelp.o grub_emu-fs_hfs.o grub_emu-fs_iso9660.o grub_emu-fs_jfs.o grub_emu-fs_minix.o grub_emu-fs_ufs.o grub_emu-kern_device.o grub_emu-kern_disk.o grub_emu-kern_dl.o grub_emu-kern_env.o grub_emu-kern_err.o grub_emu-kern_file.o grub_emu-kern_fs.o grub_emu-kern_loader.o grub_emu-kern_main.o grub_emu-kern_misc.o grub_emu-kern_partition.o grub_emu-kern_rescue.o grub_emu-kern_term.o grub_emu-normal_arg.o grub_emu-normal_cmdline.o grub_emu-normal_command.o grub_emu-normal_context.o grub_emu-normal_main.o grub_emu-normal_menu.o grub_emu-normal_menu_entry.o grub_emu-partmap_amiga.o grub_emu-partmap_apple.o grub_emu-partmap_pc.o grub_emu-partmap_sun.o grub_emu-util_console.o grub_emu-util_grub_emu.o grub_emu-util_misc.o grub_emu-util_i386_pc_biosdisk.o grub_emu-util_i386_pc_getroot.o grub_emu-util_i386_pc_misc.o grub_emu-normal_parser.o $(BUILD_CC) -o $@ $^ $(BUILD_LDFLAGS) $(grub_emu_LDFLAGS) grub_emu-commands_boot.o: commands/boot.c
@@ -1101,6 +1101,14 @@ -include grub_emu-util_i386_pc_misc.d +grub_emu-normal_parser.o: normal/parser.c + $(BUILD_CC) -Inormal -I$(srcdir)/normal $(BUILD_CPPFLAGS) $(BUILD_CFLAGS) -DGRUB_UTIL=1 $(grub_emu_CFLAGS) -c -o $@ $< + +grub_emu-normal_parser.d: normal/parser.c + set -e; $(BUILD_CC) -Inormal -I$(srcdir)/normal $(BUILD_CPPFLAGS) $(BUILD_CFLAGS) -DGRUB_UTIL=1 $(grub_emu_CFLAGS) -M $< | sed 's,parser\.o[ :]*,grub_emu-normal_parser.o $@ : ,g' > $@; [ -s $@ ] || rm -f $@ + +-include grub_emu-normal_parser.d + grub_emu_LDFLAGS = $(LIBCURSES)
@@ -1699,9 +1707,9 @@ # For normal.mod. normal_mod_SOURCES = normal/arg.c normal/cmdline.c normal/command.c \ normal/context.c normal/main.c normal/menu.c \ - normal/menu_entry.c normal/i386/setjmp.S -CLEANFILES += normal.mod mod-normal.o mod-normal.c pre-normal.o normal_mod-normal_arg.o normal_mod-normal_cmdline.o normal_mod-normal_command.o normal_mod-normal_context.o normal_mod-normal_main.o normal_mod-normal_menu.o normal_mod-normal_menu_entry.o normal_mod-normal_i386_setjmp.o def-normal.lst und-normal.lst -MOSTLYCLEANFILES += normal_mod-normal_arg.d normal_mod-normal_cmdline.d normal_mod-normal_command.d normal_mod-normal_context.d normal_mod-normal_main.d normal_mod-normal_menu.d normal_mod-normal_menu_entry.d normal_mod-normal_i386_setjmp.d + normal/menu_entry.c normal/i386/setjmp.S normal/parser.c +CLEANFILES += normal.mod mod-normal.o mod-normal.c pre-normal.o normal_mod-normal_arg.o normal_mod-normal_cmdline.o normal_mod-normal_command.o normal_mod-normal_context.o normal_mod-normal_main.o normal_mod-normal_menu.o normal_mod-normal_menu_entry.o normal_mod-normal_i386_setjmp.o normal_mod-normal_parser.o def-normal.lst und-normal.lst +MOSTLYCLEANFILES += normal_mod-normal_arg.d normal_mod-normal_cmdline.d normal_mod-normal_command.d normal_mod-normal_context.d normal_mod-normal_main.d normal_mod-normal_menu.d normal_mod-normal_menu_entry.d normal_mod-normal_i386_setjmp.d normal_mod-normal_parser.d DEFSYMFILES += def-normal.lst UNDSYMFILES += und-normal.lst
@@ -1710,7 +1718,7 @@ $(LD) -r -d -o $@ $^ $(STRIP) --strip-unneeded -K grub_mod_init -K grub_mod_fini -R .note -R .comment $@ -pre-normal.o: normal_mod-normal_arg.o normal_mod-normal_cmdline.o normal_mod-normal_command.o normal_mod-normal_context.o normal_mod-normal_main.o normal_mod-normal_menu.o normal_mod-normal_menu_entry.o normal_mod-normal_i386_setjmp.o +pre-normal.o: normal_mod-normal_arg.o normal_mod-normal_cmdline.o normal_mod-normal_command.o normal_mod-normal_context.o normal_mod-normal_main.o normal_mod-normal_menu.o normal_mod-normal_menu_entry.o normal_mod-normal_i386_setjmp.o normal_mod-normal_parser.o -rm -f $@ $(LD) -r -d -o $@ $^
@@ -1879,6 +1887,25 @@ set -e; $(CC) -Inormal/i386 -I$(srcdir)/normal/i386 $(CPPFLAGS) $(ASFLAGS) $(normal_mod_ASFLAGS) -E $< | sh $(srcdir)/genfslist.sh normal > $@ || (rm -f $@; exit 1) +normal_mod-normal_parser.o: normal/parser.c + $(CC) -Inormal -I$(srcdir)/normal $(CPPFLAGS) $(CFLAGS) $(normal_mod_CFLAGS) -c -o $@ $< + +normal_mod-normal_parser.d: normal/parser.c + set -e; $(CC) -Inormal -I$(srcdir)/normal $(CPPFLAGS) $(CFLAGS) $(normal_mod_CFLAGS) -M $< | sed 's,parser\.o[ :]*,normal_mod-normal_parser.o $@ : ,g' > $@; [ -s $@ ] || rm -f $@ + +-include normal_mod-normal_parser.d + +CLEANFILES += cmd-parser.lst fs-parser.lst +COMMANDFILES += cmd-parser.lst +FSFILES += fs-parser.lst + +cmd-parser.lst: normal/parser.c gencmdlist.sh + set -e; $(CC) -Inormal -I$(srcdir)/normal $(CPPFLAGS) $(CFLAGS) $(normal_mod_CFLAGS) -E $< | sh $(srcdir)/gencmdlist.sh normal > $@ || (rm -f $@; exit 1) + +fs-parser.lst: normal/parser.c genfslist.sh + set -e; $(CC) -Inormal -I$(srcdir)/normal $(CPPFLAGS) $(CFLAGS) $(normal_mod_CFLAGS) -E $< | sh $(srcdir)/genfslist.sh normal > $@ || (rm -f $@; exit 1) + + normal_mod_CFLAGS = $(COMMON_CFLAGS) normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
grub2_4/conf/i386-pc.rmk renamed from grub2_3/conf/i386-pc.rmk +2 -2
@@ -90,7 +90,7 @@ partmap/amiga.c partmap/apple.c partmap/pc.c partmap/sun.c \ util/console.c util/grub-emu.c util/misc.c \ util/i386/pc/biosdisk.c util/i386/pc/getroot.c \ - util/i386/pc/misc.c + util/i386/pc/misc.c normal/parser.c grub_emu_LDFLAGS = $(LIBCURSES)
@@ -163,7 +163,7 @@ # For normal.mod. normal_mod_SOURCES = normal/arg.c normal/cmdline.c normal/command.c \ normal/context.c normal/main.c normal/menu.c \ - normal/menu_entry.c normal/i386/setjmp.S + normal/menu_entry.c normal/i386/setjmp.S normal/parser.c normal_mod_CFLAGS = $(COMMON_CFLAGS) normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
grub2_4/conf/powerpc-ieee1275.mk renamed from grub2_3/conf/powerpc-ieee1275.mk +35 -8
74 lines not on this page · raw message
grub2_4/conf/powerpc-ieee1275.rmk renamed from grub2_3/conf/powerpc-ieee1275.rmk +2 -2
@@ -48,7 +48,7 @@ partmap/amiga.c partmap/apple.c partmap/pc.c partmap/sun.c \ util/console.c util/grub-emu.c util/misc.c \ util/i386/pc/biosdisk.c util/i386/pc/getroot.c \ - util/powerpc/ieee1275/misc.c + util/powerpc/ieee1275/misc.c normal/parser.c grub_emu_LDFLAGS = $(LIBCURSES)
@@ -119,7 +119,7 @@ normal_mod_SOURCES = normal/arg.c normal/cmdline.c normal/command.c \ normal/context.c normal/main.c normal/menu.c \ normal/menu_entry.c \ - normal/powerpc/setjmp.S + normal/powerpc/setjmp.S normal/parser.c normal_mod_CFLAGS = $(COMMON_CFLAGS) normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
grub2_4/include/grub/err.h renamed from grub2_3/include/grub/err.h +3 -1
@@ -49,7 +49,9 @@GRUB_ERR_NO_KERNEL ,GRUB_ERR_BAD_FONT ,GRUB_ERR_NOT_IMPLEMENTED_YET , - GRUB_ERR_SYMLINK_LOOP +GRUB_ERR_SYMLINK_LOOP , +GRUB_ERR_PARSE , + GRUB_ERR_FALSE } grub_err_t;
grub2_4/include/grub/script.h renamed from grub2_3/include/grub/script.h +92 -0
92 lines not on this page · raw message
grub2_4/normal/command.c renamed from grub2_3/normal/command.c +55 -51
139 lines not on this page · raw message
grub2_4/normal/parser.y renamed from grub2_3/normal/parser.y +717 -0
717 lines not on this page · raw message
Re: [Patch] Scripting engine
Quoted 2 lines · Vladimir Serbinenko
I wrote the preciew version of scripting engine. I'll add some comments soonly.
I'd like to see a kind of "design document", since it is a bit hard for others to understand.
Quoted 3 lines
It would be good if then it
could be incorporated
to CVS because it would be easy to developpe and debug.
We must wait until your assignment is finished. How is it going?
Okuji
Re: [Patch] Scripting engine
Quoted 5 lines
I'd like to see a kind of "design document", since it is a bit hard for others to understand.
Ok. I hope to write it this week (my studies begin tomorrow)
Quoted 6 lines
We must wait until your assignment is finished. How is it going?
No problem. I meant after assignment. I sent it back to FSF about 2 weeks ago.
Vladimir
Re: [Patch] Scripting engine
In reply to Vladimir SerbinenkoQuoted 8 lines · Vladimir Serbinenko
I wrote the preciew version of scripting engine. I'll add some comments soonly.
Parser parses everytime one command because the commands could be entered from
commandline. Bison converts in kind of pseudocode. Arithmethic support will be done
by separate parser because arithmetic parse is very different form bash one.
Can't this be done in the same bison parser? Or what do you mean?
I noticed that you have hand written yylex, wouldn't it be a lot easier to use flex for this? In that case you can easily detect tokens using regular expressions. This makes maintaining the tokenizer really easy.
Thanks,
Marco
Re: [Patch] Scripting engine
Quoted 4 lines · Marco Gerards
Can't this be done in the same bison parser? Or what do you mean?
I don't think so. Even the tokenization is very differetn. Ex:
2+3*5 is one token for normal parsing, but five for arithmethic and yylex knows nothing about what parsing is now. If it would always issue 5 tokens it would be impossible to difference
2+3*5 and 2 + 3 * 5 And yylex normally must not issue the space - it would make bison parser too complicated
Quoted 6 lines
I noticed that you have hand written yylex, wouldn't it be a lot easier to use flex for this? In that case you can easily detect tokens using regular expressions. This makes maintaining the tokenizer really easy.
For bash regular expression is not really needed. There are only 3 types of tokens:
reserved words (if, ...), normal words (WORD) and command separators (; and ENTER).
All token except WORD could be easily recognized by simple comparing (check_for_keyword function). But WORD needs special treatment because its value
is partially unknown that's why I use superchar structure (it keeps known parts as well as
necessary information to determine the value of unknown parts)
Vladimir
Re: [Patch] Scripting engine
In reply to Yoshinori K. OkujiUnfortunately I haven't had a lot of time to work with GRUB2. I'll have some more when my holidays begin in mid October.
Quoted 5 lines · Yoshinori K. Okuji
I'd like to see a kind of "design document", since it is a bit hard for others to understand.
Ok. I send one with this mail. Perhaps it would be good to add a folder for developpement docs and standartisize the format. What about /devdocs and html?
Quoted 4 lines
We must wait until your assignment is finished. How is it going?
It's strange. It's already a month that I sent my assignment and I've still nothing received.
Vladimir
------------------------------------------------------------------
The scripting engine is separated into 2 parts: parser and executer. Parser is wirtten with bison using hand-written yylex. It transforms one command into grub_script_commandlist. This structure represents a chain of commands in the form of linked list. Every single command is represented by grub_script_command. Which has the following fields:
enum grub_script_command_type type
which indicates what command it is:GRUB_SCRIPT_COMMAND_NORMAL - just a non-scripting command GRUB_SCRIPT_COMMAND_FORIN - used for for..in.. GRUB_SCRIPT_COMMAND_LOOKUP - used for block-end keyword like done, fi indicating to interpreter to relaunch or end the loop
enum grub_script_command_chain
which indicates how this command is linked with previous: independent, with && or with ||.
flags: command flags. Now only GRUB_SCRIPT_COMMAND_FLAG_NOT (command was with !) is defined.
non-scripting command:
struct grub_script_superchars *normal - a non-scripting command to execute. for...in:
struct grub_script_superchars *var - a variable to set
struct grub_script_superchars *vals - the values to set to var struct grub_script_commandlist *lookup - where the end of loop is.
grub_script_sueprchar is used to store the strings. char * is unappropriated because value of the string is unknown at parsing time. it's separated in chunks which are represented in linked list. There are 4 types of chunks: plain (just a string), variable ($var), arithmethic ($((expression))) and command (cmd or $(cmd)) to transform to char* superchartostring is used.
grub_script_superchars is used to store array of strings like command with arguments a variable list. supercharstostrings is used to transform to char**
terminal tokens:
ENTER: '\n'
FOR: "for" keyword
SEMICOLON: ';'
IN: "in" keyword
DO: "do" keyword
DONE: "done" keyword
NOP: not used
WORD: any word, that is not a keyword. Represented like superchars
OR: "||" keyword
AND: "&&" keyword
NOT: '!' keyword
other symbols
out: output
commandlist : list of commands
arglist : list of words (like not scripting command with arguments or vallist for for..in)
command :
execlist : list of inter-linked (by || or &&) commands
pre_command : solitary command that waits for ||, &&, ; or newline
cmdend: end of execlist (; or newline)
I hope that this small design document will help. All propositions and questions are welcome.