Move loader.c out of the kernel

Move loader.c out of the kernel

[phcoder]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

Hello. Now when boot command isn't in kernel anymore I don't see why 
loader.c stays in kernel. Here is the patch to move it to boot.mod
2009-03-22  Vladimir Serbinenko <phcoder@gmail.com>

	Move loader out of the kernel

	* kern/loader.c: moved to ...
	* commands/boot.c: ... moved here
	* commands/minicmd.c (grub_mini_cmd_boot): moved to ...
	* commands/boot.c (grub_cmd_boot): moved here. All users updated
	* include/grub/kernel.h (grub_machine_fini): export
	* include/grub/loader.h (grub_loader_is_loaded): update declaration
	(grub_loader_set): likewise
	(grub_loader_unset): likewise
	(grub_loader_boot): likewise
	* conf/common.rmk: new module boot.mod
	(pkglib_MODULES): add boot.mod
	* conf/i386-coreboot.rmk (kernel_elf_SOURCES): remove kern/loader.c
	(grub_emu_SOURCES): likewise
	* conf/i386-efi.rmk (kernel_elf_SOURCES): likewise
	(grub_emu_SOURCES): likewise
	* conf/i386-ieee1275.rmk (kernel_elf_SOURCES): likewise
	(grub_emu_SOURCES): likewise
	* conf/i386-pc.rmk (kernel_elf_SOURCES): likewise
	(grub_emu_SOURCES): likewise
	* conf/powerpc-ieee1275.rmk (kernel_elf_SOURCES): likewise
	(grub_emu_SOURCES): likewise
	* conf/sparcs64-ieee1275.rmk (kernel_elf_SOURCES): likewise
	(grub_emu_SOURCES): likewise	
	* conf/x86_64-efi.rmk (kernel_elf_SOURCES): likewise
	(grub_emu_SOURCES): likewise


-- 

Regards
Vladimir 'phcoder' Serbinenko

[-- Attachment #2: bootmove.diff --]
[-- Type: text/x-patch, Size: 17549 bytes --]

--- a/commands/boot.c
+++ b/commands/boot.c
@@ -1,7 +1,7 @@
 /* boot.c - command to boot an operating system */
 /*
  *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2003,2005,2007  Free Software Foundation, Inc.
+ *  Copyright (C) 2002,2003,2004,2005,2007,2009  Free Software Foundation, Inc.
  *
  *  GRUB is free software: you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -21,29 +21,82 @@
 #include <grub/dl.h>
 #include <grub/misc.h>
 #include <grub/loader.h>
+#include <grub/kernel.h>
 
-static grub_err_t
-grub_cmd_boot (struct grub_arg_list *state __attribute__ ((unused)),
-	       int argc, char **args __attribute__ ((unused)))
+static grub_err_t (*grub_loader_boot_func) (void);
+static grub_err_t (*grub_loader_unload_func) (void);
+static int grub_loader_noreturn;
+
+static int grub_loader_loaded;
+
+int
+grub_loader_is_loaded (void)
+{
+  return grub_loader_loaded;
+}
+
+void
+grub_loader_set (grub_err_t (*boot) (void),
+		 grub_err_t (*unload) (void),
+		 int noreturn)
+{
+  if (grub_loader_loaded && grub_loader_unload_func)
+    grub_loader_unload_func ();
+  
+  grub_loader_boot_func = boot;
+  grub_loader_unload_func = unload;
+  grub_loader_noreturn = noreturn;
+  
+  grub_loader_loaded = 1;
+}
+
+void
+grub_loader_unset(void)
 {
-  if (argc)
-    return grub_error (GRUB_ERR_BAD_ARGUMENT, "too many arguments");
+  if (grub_loader_loaded && grub_loader_unload_func)
+    grub_loader_unload_func ();
   
-  grub_loader_boot ();
+  grub_loader_boot_func = 0;
+  grub_loader_unload_func = 0;
+
+  grub_loader_loaded = 0;
+}
+
+grub_err_t
+grub_loader_boot (void)
+{
+  if (! grub_loader_loaded)
+    return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");
+
+  if (grub_loader_noreturn)
+    grub_machine_fini ();
   
-  return 0;
+  return (grub_loader_boot_func) ();
+}
+
+
+/* boot */
+static grub_err_t
+grub_cmd_boot (struct grub_command *cmd __attribute__ ((unused)),
+		    int argc __attribute__ ((unused)),
+		    char *argv[] __attribute__ ((unused)))
+{
+  return grub_loader_boot ();
 }
 
 \f
 
+static grub_command_t cmd_boot;
+
 GRUB_MOD_INIT(boot)
 {
   (void) mod;			/* To stop warning. */
-  grub_register_command ("boot", grub_cmd_boot, GRUB_COMMAND_FLAG_BOTH,
-			 "boot", "Boot an operating system.", 0);
+  cmd_boot =
+    grub_register_command ("boot", grub_cmd_boot,
+			   0, "boot an operating system");
 }
 
 GRUB_MOD_FINI(boot)
 {
-  grub_unregister_command ("boot");
+  grub_unregister_command (cmd_boot);
 }
diff --git a/commands/minicmd.c b/commands/minicmd.c
index 071c889..5083291 100644
--- a/commands/minicmd.c
+++ b/commands/minicmd.c
@@ -1,7 +1,7 @@
 /* minicmd.c - commands for the rescue mode */
 /*
  *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2003,2005,2006,2007  Free Software Foundation, Inc.
+ *  Copyright (C) 2003,2005,2006,2007,2009  Free Software Foundation, Inc.
  *
  *  GRUB is free software: you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -28,15 +28,6 @@
 #include <grub/loader.h>
 #include <grub/command.h>
 
-/* boot */
-static grub_err_t
-grub_mini_cmd_boot (struct grub_command *cmd __attribute__ ((unused)),
-		    int argc __attribute__ ((unused)),
-		    char *argv[] __attribute__ ((unused)))
-{
-  return grub_loader_boot ();
-}
-
 /* cat FILE */
 static grub_err_t
 grub_mini_cmd_cat (struct grub_command *cmd __attribute__ ((unused)),
@@ -345,16 +336,13 @@ grub_mini_cmd_exit (struct grub_command *cmd __attribute__ ((unused)),
   return 0;
 }
 
-static grub_command_t cmd_boot, cmd_cat, cmd_help, cmd_root;
+static grub_command_t cmd_cat, cmd_help, cmd_root;
 static grub_command_t cmd_dump, cmd_rmmod, cmd_lsmod, cmd_exit;
 
 GRUB_MOD_INIT(minicmd)
 {
   (void) mod;			/* To stop warning. */
 
-  cmd_boot =
-    grub_register_command ("boot", grub_mini_cmd_boot,
-			   0, "boot an operating system");
   cmd_cat =
     grub_register_command ("cat", grub_mini_cmd_cat,
 			   "cat FILE", "show the contents of a file");
@@ -380,7 +368,6 @@ GRUB_MOD_INIT(minicmd)
 
 GRUB_MOD_FINI(minicmd)
 {
-  grub_unregister_command (cmd_boot);
   grub_unregister_command (cmd_cat);
   grub_unregister_command (cmd_help);
   grub_unregister_command (cmd_root);
diff --git a/conf/common.rmk b/conf/common.rmk
index 43bc683..062d6b6 100644
--- a/conf/common.rmk
+++ b/conf/common.rmk
@@ -335,7 +335,12 @@ pkglib_MODULES += minicmd.mod extcmd.mod hello.mod handler.mod	\
 	 ls.mod	cmp.mod cat.mod help.mod search.mod		\
 	loopback.mod fs_uuid.mod configfile.mod echo.mod	\
 	terminfo.mod test.mod blocklist.mod hexdump.mod		\
-	read.mod sleep.mod loadenv.mod crc.mod
+	read.mod sleep.mod loadenv.mod crc.mod boot.mod
+
+# For boot.mod.
+boot_mod_SOURCES = commands/boot.c
+boot_mod_CFLAGS = $(COMMON_CFLAGS)
+boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # For minicmd.mod.
 minicmd_mod_SOURCES = commands/minicmd.c
diff --git a/conf/i386-coreboot.rmk b/conf/i386-coreboot.rmk
index 0b4f216..018f0a5 100644
--- a/conf/i386-coreboot.rmk
+++ b/conf/i386-coreboot.rmk
@@ -16,7 +16,7 @@ kernel_elf_SOURCES = kern/i386/coreboot/startup.S \
 	kern/i386/multiboot_mmap.c \
 	kern/main.c kern/device.c \
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c \
 	kern/time.c kern/list.c kern/handler.c kern/command.c kern/corecmd.c \
 	kern/i386/dl.c kern/parser.c kern/partition.c \
 	kern/i386/tsc.c kern/i386/pit.c \
@@ -73,7 +73,7 @@ grub_emu_SOURCES = commands/minicmd.c commands/cat.c commands/cmp.c	\
 	kern/err.c kern/list.c kern/handler.c				\
 	kern/command.c kern/corecmd.c commands/extcmd.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	commands/boot.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	lib/arg.c normal/cmdline.c normal/command.c normal/function.c\
 	normal/completion.c normal/main.c normal/menu_text.c		\
diff --git a/conf/i386-efi.rmk b/conf/i386-efi.rmk
index 18a99df..0b5928b 100644
--- a/conf/i386-efi.rmk
+++ b/conf/i386-efi.rmk
@@ -50,7 +50,7 @@ grub_emu_SOURCES = commands/minicmd.c commands/cat.c commands/cmp.c 	\
 	kern/err.c kern/list.c kern/handler.c				\
 	kern/command.c kern/corecmd.c commands/extcmd.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	commands/boot.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	lib/arg.c normal/cmdline.c normal/command.c normal/function.c	\
 	normal/completion.c normal/context.c normal/main.c		\
@@ -85,7 +85,7 @@ pkglib_MODULES = kernel.mod normal.mod chain.mod appleldr.mod \
 kernel_mod_EXPORTS = no
 kernel_mod_SOURCES = kern/i386/efi/startup.S kern/main.c kern/device.c \
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c \
 	kern/i386/dl.c kern/i386/efi/init.c kern/parser.c kern/partition.c \
 	kern/env.c symlist.c kern/efi/efi.c kern/efi/init.c kern/efi/mm.c \
 	term/efi/console.c disk/efi/efidisk.c \
diff --git a/conf/i386-ieee1275.rmk b/conf/i386-ieee1275.rmk
index dbcbb4a..144ff66 100644
--- a/conf/i386-ieee1275.rmk
+++ b/conf/i386-ieee1275.rmk
@@ -17,7 +17,7 @@ kernel_elf_SOURCES = kern/i386/ieee1275/startup.S kern/i386/ieee1275/init.c \
 	kern/ieee1275/cmain.c kern/ieee1275/openfw.c \
 	kern/main.c kern/device.c \
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c \
 	kern/i386/dl.c kern/parser.c kern/partition.c \
 	kern/env.c \
 	kern/time.c kern/list.c kern/handler.c kern/command.c kern/corecmd.c \
@@ -73,7 +73,7 @@ grub_emu_SOURCES = commands/minicmd.c commands/cat.c commands/cmp.c	\
 	kern/err.c kern/list.c kern/handler.c				\
 	kern/command.c kern/corecmd.c commands/extcmd.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	commands/boot.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	lib/arg.c normal/cmdline.c normal/command.c normal/function.c\
 	normal/completion.c normal/main.c normal/menu_text.c		\
diff --git a/conf/i386-pc.rmk b/conf/i386-pc.rmk
index cc845ed..fae505b 100644
--- a/conf/i386-pc.rmk
+++ b/conf/i386-pc.rmk
@@ -41,7 +41,7 @@ cdboot_img_LDFLAGS = $(COMMON_LDFLAGS) $(TARGET_IMG_LDFLAGS) -Wl,-Ttext,7C00
 # For kernel.img.
 kernel_img_SOURCES = kern/i386/pc/startup.S kern/main.c kern/device.c \
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c \
 	kern/time.c kern/list.c kern/handler.c kern/command.c kern/corecmd.c \
 	kern/i386/dl.c kern/i386/pc/init.c kern/i386/pc/mmap.c \
 	kern/parser.c kern/partition.c \
@@ -126,7 +126,7 @@ grub_emu_SOURCES = commands/minicmd.c commands/cat.c commands/cmp.c	\
 	kern/err.c kern/list.c kern/handler.c				\
 	kern/command.c kern/corecmd.c commands/extcmd.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	commands/boot.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	lib/arg.c normal/cmdline.c normal/command.c normal/function.c	\
 	normal/completion.c normal/main.c normal/color.c		\
diff --git a/conf/powerpc-ieee1275.rmk b/conf/powerpc-ieee1275.rmk
index 5aaaf56..825341a 100644
--- a/conf/powerpc-ieee1275.rmk
+++ b/conf/powerpc-ieee1275.rmk
@@ -52,7 +52,7 @@ grub_emu_SOURCES = commands/minicmd.c commands/cat.c commands/cmp.c 	\
 	\
 	io/gzio.c							\
 	kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c	\
-	kern/err.c kern/file.c kern/fs.c kern/loader.c kern/main.c	\
+	kern/err.c kern/file.c kern/fs.c commands/boot.c kern/main.c	\
 	kern/misc.c kern/parser.c kern/partition.c kern/rescue.c	\
 	kern/term.c kern/list.c kern/handler.c fs/fshelp.c		\
 	kern/command.c kern/corecmd.c commands/extcmd.c			\
@@ -78,7 +78,7 @@ grub_emu_LDFLAGS = $(LIBCURSES)
 kernel_elf_SOURCES = kern/powerpc/ieee1275/startup.S kern/ieee1275/cmain.c \
 	kern/ieee1275/ieee1275.c kern/main.c kern/device.c 		\
 	kern/disk.c kern/dl.c kern/err.c kern/file.c kern/fs.c 		\
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c 	\
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c 	\
 	kern/list.c kern/handler.c kern/command.c kern/corecmd.c	\
 	kern/ieee1275/init.c 						\
 	kern/ieee1275/mmap.c						\
diff --git a/conf/sparc64-ieee1275.rmk b/conf/sparc64-ieee1275.rmk
index 1658a66..66eaae6 100644
--- a/conf/sparc64-ieee1275.rmk
+++ b/conf/sparc64-ieee1275.rmk
@@ -53,7 +53,7 @@ grub_mkimage_SOURCES = util/sparc64/ieee1275/grub-mkimage.c util/misc.c \
 #	grub_script.tab.c						\
 #	io/gzio.c                                                       \
 #	kern/device.c kern/disk.c kern/dl.c kern/env.c kern/err.c 	\
-#	kern/file.c kern/fs.c kern/loader.c kern/main.c kern/misc.c	\
+#	kern/file.c kern/fs.c commands/boot.c kern/main.c kern/misc.c	\
 #	kern/parser.c kern/partition.c kern/rescue.c kern/term.c	\
 #	kern/list.c kern/handler.c					\
 #	normal/arg.c normal/cmdline.c normal/command.c			\
@@ -72,7 +72,7 @@ grub_emu_LDFLAGS = $(LIBCURSES)
 
 kernel_elf_SOURCES = kern/sparc64/ieee1275/init.c kern/ieee1275/ieee1275.c \
 	kern/main.c kern/device.c kern/disk.c kern/dl.c kern/file.c \
-	kern/fs.c kern/err.c kern/misc.c kern/mm.c kern/loader.c \
+	kern/fs.c kern/err.c kern/misc.c kern/mm.c  \
 	kern/rescue.c kern/term.c term/ieee1275/ofconsole.c \
 	kern/sparc64/ieee1275/openfw.c disk/ieee1275/ofdisk.c \
 	kern/partition.c kern/env.c kern/sparc64/dl.c symlist.c \
diff --git a/conf/x86_64-efi.rmk b/conf/x86_64-efi.rmk
index faa59fb..37d983f 100644
--- a/conf/x86_64-efi.rmk
+++ b/conf/x86_64-efi.rmk
@@ -52,7 +52,7 @@ grub_emu_SOURCES = commands/minicmd.c commands/cat.c commands/cmp.c 	\
 	kern/err.c kern/list.c kern/handler.c				\
 	kern/command.c kern/corecmd.c commands/extcmd.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	commands/boot.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	lib/arg.c normal/cmdline.c normal/command.c normal/function.c\
 	normal/completion.c normal/context.c normal/main.c		\
@@ -88,7 +88,7 @@ kernel_mod_EXPORTS = no
 kernel_mod_SOURCES = kern/x86_64/efi/startup.S kern/x86_64/efi/callwrap.S \
 	kern/main.c kern/device.c \
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c \
 	kern/x86_64/dl.c kern/i386/efi/init.c kern/parser.c kern/partition.c \
 	kern/env.c symlist.c kern/efi/efi.c kern/efi/init.c kern/efi/mm.c \
 	kern/time.c kern/list.c kern/handler.c kern/command.c kern/corecmd.c \
diff --git a/include/grub/kernel.h b/include/grub/kernel.h
index adaee58..74aca40 100644
--- a/include/grub/kernel.h
+++ b/include/grub/kernel.h
@@ -1,6 +1,6 @@
 /*
  *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2002,2005,2006,2007,2008  Free Software Foundation, Inc.
+ *  Copyright (C) 2002,2005,2006,2007,2008,2009  Free Software Foundation, Inc.
  *
  *  GRUB is free software: you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -64,7 +64,7 @@ void grub_main (void);
 void grub_machine_init (void);
 
 /* The machine-specific finalization.  */
-void grub_machine_fini (void);
+void EXPORT_FUNC(grub_machine_fini) (void);
 
 /* The machine-specific prefix initialization.  */
 void grub_machine_set_prefix (void);
diff --git a/include/grub/loader.h b/include/grub/loader.h
index 1ae5fdd..185d297 100644
--- a/include/grub/loader.h
+++ b/include/grub/loader.h
@@ -1,7 +1,7 @@
 /* loader.h - OS loaders */
 /*
  *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2002,2003,2004,2006,2007  Free Software Foundation, Inc.
+ *  Copyright (C) 2002,2003,2004,2006,2007,2009  Free Software Foundation, Inc.
  *
  *  GRUB is free software: you can redistribute it and/or modify
  *  it under the terms of the GNU General Public License as published by
@@ -26,19 +26,19 @@
 #include <grub/types.h>
 
 /* Check if a loader is loaded.  */
-int EXPORT_FUNC(grub_loader_is_loaded) (void);
+int grub_loader_is_loaded (void);
 
 /* Set loader functions. NORETURN must be set to true, if BOOT won't return
    to the original state.  */
-void EXPORT_FUNC(grub_loader_set) (grub_err_t (*boot) (void),
-				   grub_err_t (*unload) (void),
-				   int noreturn);
+void grub_loader_set (grub_err_t (*boot) (void),
+		      grub_err_t (*unload) (void),
+		      int noreturn);
 
 /* Unset current loader, if any.  */
-void EXPORT_FUNC(grub_loader_unset) (void);
+void grub_loader_unset (void);
 
 /* Call the boot hook in current loader. This may or may not return,
    depending on the setting by grub_loader_set.  */
-grub_err_t EXPORT_FUNC(grub_loader_boot) (void);
+grub_err_t grub_loader_boot (void);
 
 #endif /* ! GRUB_LOADER_HEADER */
diff --git a/kern/loader.c b/kern/loader.c
deleted file mode 100644
index 2b67d49..0000000
--- a/kern/loader.c
+++ /dev/null
@@ -1,75 +0,0 @@
-/*
- *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2002,2003,2004,2006,2007  Free Software Foundation, Inc.
- *
- *  GRUB is free software: you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
- *  (at your option) any later version.
- *
- *  GRUB is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <grub/loader.h>
-#include <grub/misc.h>
-#include <grub/mm.h>
-#include <grub/err.h>
-#include <grub/kernel.h>
-
-static grub_err_t (*grub_loader_boot_func) (void);
-static grub_err_t (*grub_loader_unload_func) (void);
-static int grub_loader_noreturn;
-
-static int grub_loader_loaded;
-
-int
-grub_loader_is_loaded (void)
-{
-  return grub_loader_loaded;
-}
-
-void
-grub_loader_set (grub_err_t (*boot) (void),
-		 grub_err_t (*unload) (void),
-		 int noreturn)
-{
-  if (grub_loader_loaded && grub_loader_unload_func)
-    grub_loader_unload_func ();
-  
-  grub_loader_boot_func = boot;
-  grub_loader_unload_func = unload;
-  grub_loader_noreturn = noreturn;
-  
-  grub_loader_loaded = 1;
-}
-
-void
-grub_loader_unset(void)
-{
-  if (grub_loader_loaded && grub_loader_unload_func)
-    grub_loader_unload_func ();
-  
-  grub_loader_boot_func = 0;
-  grub_loader_unload_func = 0;
-
-  grub_loader_loaded = 0;
-}
-
-grub_err_t
-grub_loader_boot (void)
-{
-  if (! grub_loader_loaded)
-    return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");
-
-  if (grub_loader_noreturn)
-    grub_machine_fini ();
-  
-  return (grub_loader_boot_func) ();
-}
-

Re: Move loader.c out of the kernel

[Yoshinori K. Okuji]

On Sunday 22 March 2009 21:48:21 phcoder wrote:
> Hello. Now when boot command isn't in kernel anymore I don't see why
> loader.c stays in kernel. Here is the patch to move it to boot.mod

This is not useful in reality, because the loader interface needs to be 
pre-loaded into core.img anyway. Note that the more you split code into 
modules, the more the size of core.img is, as long as they are all 
pre-loaded.

Regards,
Okuji

Re: Move loader.c out of the kernel

[phcoder]

Yoshinori K. Okuji wrote:
> On Sunday 22 March 2009 21:48:21 phcoder wrote:
>> Hello. Now when boot command isn't in kernel anymore I don't see why
>> loader.c stays in kernel. Here is the patch to move it to boot.mod
> 
> This is not useful in reality, because the loader interface needs to be 
> pre-loaded into core.img anyway.

Why? I successfully tested core.img with just pc fat and biosdisk 
modules integrated. It loads boot.mod just fine and boots linux and 
multiboot with no problem

 > Note that the more you split code into
> modules, the more the size of core.img is, as long as they are all 
> pre-loaded.
> 
> Regards,
> Okuji
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Move loader.c out of the kernel

[Yoshinori K. Okuji]

On Sunday 22 March 2009 22:06:36 phcoder wrote:
> Yoshinori K. Okuji wrote:
> > On Sunday 22 March 2009 21:48:21 phcoder wrote:
> >> Hello. Now when boot command isn't in kernel anymore I don't see why
> >> loader.c stays in kernel. Here is the patch to move it to boot.mod
> >
> > This is not useful in reality, because the loader interface needs to be
> > pre-loaded into core.img anyway.
>
> Why? I successfully tested core.img with just pc fat and biosdisk
> modules integrated. It loads boot.mod just fine and boots linux and
> multiboot with no problem

Try the rescue mode with no extra module loaded. If the core.img does not have 
any loader, it is useless.

Okuji

>
>  > Note that the more you split code into
> >
> > modules, the more the size of core.img is, as long as they are all
> > pre-loaded.
> >
> > Regards,
> > Okuji
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Move loader.c out of the kernel

[phcoder]

Yoshinori K. Okuji wrote:
> On Sunday 22 March 2009 22:06:36 phcoder wrote:
>> Yoshinori K. Okuji wrote:
>>> On Sunday 22 March 2009 21:48:21 phcoder wrote:
>>>> Hello. Now when boot command isn't in kernel anymore I don't see why
>>>> loader.c stays in kernel. Here is the patch to move it to boot.mod
>>> This is not useful in reality, because the loader interface needs to be
>>> pre-loaded into core.img anyway.
>> Why? I successfully tested core.img with just pc fat and biosdisk
>> modules integrated. It loads boot.mod just fine and boots linux and
>> multiboot with no problem
> 
> Try the rescue mode with no extra module loaded. If the core.img does not have 
> any loader, it is useless.
If it's unable to read FS then it can't boot much anyway. If it's it can 
load modules from its own partition. The only use I see is when grub 
partition is corrupted but OS one is intact and you already have FS 
driver for root in grub2.
Alternatively commands/boot.c can be a part of minicmd

> 
> Okuji
> 
>>  > Note that the more you split code into
>>> modules, the more the size of core.img is, as long as they are all
>>> pre-loaded.
>>>
>>> Regards,
>>> Okuji
>>>
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Move loader.c out of the kernel

[Yoshinori K. Okuji]

On Sunday 22 March 2009 22:30:24 phcoder wrote:
> Yoshinori K. Okuji wrote:
> > On Sunday 22 March 2009 22:06:36 phcoder wrote:
> >> Yoshinori K. Okuji wrote:
> >>> On Sunday 22 March 2009 21:48:21 phcoder wrote:
> >>>> Hello. Now when boot command isn't in kernel anymore I don't see why
> >>>> loader.c stays in kernel. Here is the patch to move it to boot.mod
> >>>
> >>> This is not useful in reality, because the loader interface needs to be
> >>> pre-loaded into core.img anyway.
> >>
> >> Why? I successfully tested core.img with just pc fat and biosdisk
> >> modules integrated. It loads boot.mod just fine and boots linux and
> >> multiboot with no problem
> >
> > Try the rescue mode with no extra module loaded. If the core.img does not
> > have any loader, it is useless.
>
> If it's unable to read FS then it can't boot much anyway. If it's it can
> load modules from its own partition. The only use I see is when grub
> partition is corrupted but OS one is intact and you already have FS
> driver for root in grub2.
> Alternatively commands/boot.c can be a part of minicmd

"cannot load any more module" != "cannot read the filesystem"

The most typical case is where the user has failed in installing GRUB 
correctly; in this case, the user can still reset the prefix, and load 
normal.mod manually. But, surprisingly, some users accidentally remove 
modules. Indeed, I have heard many times this kind of "bug reports" in GRUB 
Legacy. In this case, the only way is to boot an OS somehow and re-install 
GRUB.

Regards,
Okuji

Re: Move loader.c out of the kernel

[phcoder]

Yoshinori K. Okuji wrote:
> On Sunday 22 March 2009 22:30:24 phcoder wrote:
>> Yoshinori K. Okuji wrote:
>>> On Sunday 22 March 2009 22:06:36 phcoder wrote:
>>>> Yoshinori K. Okuji wrote:
>>>>> On Sunday 22 March 2009 21:48:21 phcoder wrote:
>>>>>> Hello. Now when boot command isn't in kernel anymore I don't see why
>>>>>> loader.c stays in kernel. Here is the patch to move it to boot.mod
>>>>> This is not useful in reality, because the loader interface needs to be
>>>>> pre-loaded into core.img anyway.
>>>> Why? I successfully tested core.img with just pc fat and biosdisk
>>>> modules integrated. It loads boot.mod just fine and boots linux and
>>>> multiboot with no problem
>>> Try the rescue mode with no extra module loaded. If the core.img does not
>>> have any loader, it is useless.
>> If it's unable to read FS then it can't boot much anyway. If it's it can
>> load modules from its own partition. The only use I see is when grub
>> partition is corrupted but OS one is intact and you already have FS
>> driver for root in grub2.
>> Alternatively commands/boot.c can be a part of minicmd
> 
> "cannot load any more module" != "cannot read the filesystem"
> 
> The most typical case is where the user has failed in installing GRUB 
> correctly; in this case, the user can still reset the prefix, and load 
> normal.mod manually. But, surprisingly, some users accidentally remove 
> modules. Indeed, I have heard many times this kind of "bug reports" in GRUB 
> Legacy. In this case, the only way is to boot an OS somehow and re-install 
> GRUB.

Well if user damages grub2 then we can't do much. He can also accidently 
  rewrite mbr or first track (some non-booting-realted software does it 
on purpose). For failsafe solution only cd is a viable alternative
grub-install already handles the correct installation of grub2. 
Additionally if user has "accidently" deleted modules chances are he 
used grub-install or some wrapper around it. But grub-install doesn't 
put any loader modules to core.img.

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


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Move loader.c out of the kernel

[Yoshinori K. Okuji]

On Sunday 22 March 2009 23:19:09 phcoder wrote:
> Yoshinori K. Okuji wrote:
> > On Sunday 22 March 2009 22:30:24 phcoder wrote:
> >> Yoshinori K. Okuji wrote:
> >>> On Sunday 22 March 2009 22:06:36 phcoder wrote:
> >>>> Yoshinori K. Okuji wrote:
> >>>>> On Sunday 22 March 2009 21:48:21 phcoder wrote:
> >>>>>> Hello. Now when boot command isn't in kernel anymore I don't see why
> >>>>>> loader.c stays in kernel. Here is the patch to move it to boot.mod
> >>>>>
> >>>>> This is not useful in reality, because the loader interface needs to
> >>>>> be pre-loaded into core.img anyway.
> >>>>
> >>>> Why? I successfully tested core.img with just pc fat and biosdisk
> >>>> modules integrated. It loads boot.mod just fine and boots linux and
> >>>> multiboot with no problem
> >>>
> >>> Try the rescue mode with no extra module loaded. If the core.img does
> >>> not have any loader, it is useless.
> >>
> >> If it's unable to read FS then it can't boot much anyway. If it's it can
> >> load modules from its own partition. The only use I see is when grub
> >> partition is corrupted but OS one is intact and you already have FS
> >> driver for root in grub2.
> >> Alternatively commands/boot.c can be a part of minicmd
> >
> > "cannot load any more module" != "cannot read the filesystem"
> >
> > The most typical case is where the user has failed in installing GRUB
> > correctly; in this case, the user can still reset the prefix, and load
> > normal.mod manually. But, surprisingly, some users accidentally remove
> > modules. Indeed, I have heard many times this kind of "bug reports" in
> > GRUB Legacy. In this case, the only way is to boot an OS somehow and
> > re-install GRUB.
>
> Well if user damages grub2 then we can't do much. He can also accidently
>   rewrite mbr or first track (some non-booting-realted software does it
> on purpose).

I know that this is very rare by experience, in comparison with just having 
removed/broke many things from/in a filesystem.

> For failsafe solution only cd is a viable alternative 

If you have experience on maintaining remote hardware, you should know that 
this is not viable.

> grub-install already handles the correct installation of grub2.
> Additionally if user has "accidently" deleted modules chances are he
> used grub-install or some wrapper around it. But grub-install doesn't
> put any loader modules to core.img.

grub-install itself does whatever the user specifies. If your core.img does 
not include necessary modules pre-loaded, that's your mistake or your 
distributor's.

Regards,
Okuji

Re: Move loader.c out of the kernel

[Robert Millan]

On Sun, Mar 22, 2009 at 11:01:41PM +0900, Yoshinori K. Okuji wrote:
> >
> > If it's unable to read FS then it can't boot much anyway. If it's it can
> > load modules from its own partition. The only use I see is when grub
> > partition is corrupted but OS one is intact and you already have FS
> > driver for root in grub2.
> > Alternatively commands/boot.c can be a part of minicmd
> 
> "cannot load any more module" != "cannot read the filesystem"
> 
> The most typical case is where the user has failed in installing GRUB 
> correctly;

In my experience dealing with grub2 bug reports in debian, the most common
case where user entered rescue mode is some bug in grub.

As grub becomes more mature, this may become less of an issue, but then again
an automated install process is provided by the distribution.  If users want
to tinker and install things by hand, and they make mistakes, I think they
should learn to either do things right or let the distribution scripts do it
for them.

Or to put it another way, "nothing is fool-proof to a sufficiently talented
fool" :-)

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Move loader.c out of the kernel

[phcoder]

With a new swing in normal.mod splitting I think we should reconsider 
this patch. It's useless to keep loader.c in kernel without boot 
command. IMO it should be moved either to a perate boot.mod (my 
preference) or to minicmd.mod (not a good option IMO)
phcoder wrote:
> Hello. Now when boot command isn't in kernel anymore I don't see why 
> loader.c stays in kernel. Here is the patch to move it to boot.mod
> 2009-03-22  Vladimir Serbinenko <phcoder@gmail.com>
> 
>     Move loader out of the kernel
> 
>     * kern/loader.c: moved to ...
>     * commands/boot.c: ... moved here
>     * commands/minicmd.c (grub_mini_cmd_boot): moved to ...
>     * commands/boot.c (grub_cmd_boot): moved here. All users updated
>     * include/grub/kernel.h (grub_machine_fini): export
>     * include/grub/loader.h (grub_loader_is_loaded): update declaration
>     (grub_loader_set): likewise
>     (grub_loader_unset): likewise
>     (grub_loader_boot): likewise
>     * conf/common.rmk: new module boot.mod
>     (pkglib_MODULES): add boot.mod
>     * conf/i386-coreboot.rmk (kernel_elf_SOURCES): remove kern/loader.c
>     (grub_emu_SOURCES): likewise
>     * conf/i386-efi.rmk (kernel_elf_SOURCES): likewise
>     (grub_emu_SOURCES): likewise
>     * conf/i386-ieee1275.rmk (kernel_elf_SOURCES): likewise
>     (grub_emu_SOURCES): likewise
>     * conf/i386-pc.rmk (kernel_elf_SOURCES): likewise
>     (grub_emu_SOURCES): likewise
>     * conf/powerpc-ieee1275.rmk (kernel_elf_SOURCES): likewise
>     (grub_emu_SOURCES): likewise
>     * conf/sparcs64-ieee1275.rmk (kernel_elf_SOURCES): likewise
>     (grub_emu_SOURCES): likewise   
>     * conf/x86_64-efi.rmk (kernel_elf_SOURCES): likewise
>     (grub_emu_SOURCES): likewise
> 
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Move loader.c out of the kernel

[Yoshinori K. Okuji]

On Tuesday 31 March 2009 17:56:24 phcoder wrote:
> With a new swing in normal.mod splitting I think we should reconsider
> this patch. It's useless to keep loader.c in kernel without boot
> command. IMO it should be moved either to a perate boot.mod (my
> preference) or to minicmd.mod (not a good option IMO)

As I said, rescue mode is not quite useful without any loader. So the loader 
interface should be built into the kernel, and the boot command should be as 
well naturally.

Regards,
Okuji

Re: Move loader.c out of the kernel

[Robert Millan]

On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote:
> On Tuesday 31 March 2009 17:56:24 phcoder wrote:
> > With a new swing in normal.mod splitting I think we should reconsider
> > this patch. It's useless to keep loader.c in kernel without boot
> > command. IMO it should be moved either to a perate boot.mod (my
> > preference) or to minicmd.mod (not a good option IMO)
> 
> As I said, rescue mode is not quite useful without any loader. So the loader 
> interface should be built into the kernel, and the boot command should be as 
> well naturally.

This presses for more space into core.img, which is highly constrained
(specially in weird combinations like raid + lvm or crypto in the future).

Why is a loader so important for rescue mode?  If the loader would work, it
means you can read files, so it should be able to load the rest of modules
as well.

When user is dumped to rescue mode, usually (at least for reports I dealt with
in debian) it means GRUB has a bug or didn't setup itself properly, and the
/boot/ directory can't be accessed.  A loader wouldn't help in these
situations.

Also, how do you determine which loaders belong in kernel?  There can be
many specialized loaders like the linux one.  Or we could just put multiboot,
but the Multiboot loader is quite complex already, and it still has room
for growing.  Maybe the answer is to write a very simple Multiboot loader
and put that in kernel?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Move loader.c out of the kernel

[Yoshinori K. Okuji]

On Wednesday 01 April 2009 23:19:32 Robert Millan wrote:
> On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote:
> > On Tuesday 31 March 2009 17:56:24 phcoder wrote:
> > > With a new swing in normal.mod splitting I think we should reconsider
> > > this patch. It's useless to keep loader.c in kernel without boot
> > > command. IMO it should be moved either to a perate boot.mod (my
> > > preference) or to minicmd.mod (not a good option IMO)
> >
> > As I said, rescue mode is not quite useful without any loader. So the
> > loader interface should be built into the kernel, and the boot command
> > should be as well naturally.
>
> This presses for more space into core.img, which is highly constrained
> (specially in weird combinations like raid + lvm or crypto in the future).
>
> Why is a loader so important for rescue mode?  If the loader would work, it
> means you can read files, so it should be able to load the rest of modules
> as well.

If some or all modules are trashed, no. Also, the user might be able to read 
other partitions.

> When user is dumped to rescue mode, usually (at least for reports I dealt
> with in debian) it means GRUB has a bug or didn't setup itself properly,
> and the /boot/ directory can't be accessed.  A loader wouldn't help in
> these situations.

And, the rescue mode does not help very much in this case.

> Also, how do you determine which loaders belong in kernel?  There can be
> many specialized loaders like the linux one.  Or we could just put
> multiboot, but the Multiboot loader is quite complex already, and it still
> has room for growing.  Maybe the answer is to write a very simple Multiboot
> loader and put that in kernel?

That's up to the user IMO. For example, suppose this kind of scenario:

- the user has a dual boot environment, say, GNU/Linux and Windows.
- she uses GRUB installed with the GNU/Linux.
- she has made something stupid in the GNU/Linux (e.g. rm -rf /).

In the case of GRUB Legacy, this is the end. It's just unbootable, because 
stage 1.5 may not boot anything besides stage2.

In the case of GRUB 2, if the user has pre-loaded chainload.mod onto the 
core.img, she can still boot the Windows.

Honestly, I am more interested in making it possible to use GRUB for setting 
up a very robust environment. For example:

- the user installs a main OS and a rescue OS into a single machine. The 
latter can be very compact (e.g. puppy, grml, etc.).
- she installs another boot loader into the partition for the rescue OS.
- she pre-loads chainload.mod in core.img.

I think the chainloader is the most realistic, because it is the smallest 
loader, and GRUB does not need to read a filesystem, thus no filesystem 
driver is required for loading an OS.

Every time I maintain a remote system, I feel the necessity of being prepared 
for disasters (e.g. filesystem crashes). Rescue mode is one of the tools 
required for this goal.

Regards,
Okuji

Re: Move loader.c out of the kernel

[phcoder]

This usage case isn't the main target case. If you embed the loader 
(which tend to be quite big) then you already have an overhead from 
loader module. Why are you so concerned with overhead of boot.mod?
But on the other hand this forces all the people in other cases to have 
boot code in core.img. I want to add preboot hooks and don't want 
increment size of kernel. multiboot.mod currently increases the size by 
around 11KB. And my patch doesn't restrict you from putting loader in 
core.img in any way
Yoshinori K. Okuji wrote:
> On Wednesday 01 April 2009 23:19:32 Robert Millan wrote:
>> On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote:
>>> On Tuesday 31 March 2009 17:56:24 phcoder wrote:
>>>> With a new swing in normal.mod splitting I think we should reconsider
>>>> this patch. It's useless to keep loader.c in kernel without boot
>>>> command. IMO it should be moved either to a perate boot.mod (my
>>>> preference) or to minicmd.mod (not a good option IMO)
>>> As I said, rescue mode is not quite useful without any loader. So the
>>> loader interface should be built into the kernel, and the boot command
>>> should be as well naturally.
>> This presses for more space into core.img, which is highly constrained
>> (specially in weird combinations like raid + lvm or crypto in the future).
>>
>> Why is a loader so important for rescue mode?  If the loader would work, it
>> means you can read files, so it should be able to load the rest of modules
>> as well.
> 
> If some or all modules are trashed, no. Also, the user might be able to read 
> other partitions.
> 
>> When user is dumped to rescue mode, usually (at least for reports I dealt
>> with in debian) it means GRUB has a bug or didn't setup itself properly,
>> and the /boot/ directory can't be accessed.  A loader wouldn't help in
>> these situations.
> 
> And, the rescue mode does not help very much in this case.
> 
>> Also, how do you determine which loaders belong in kernel?  There can be
>> many specialized loaders like the linux one.  Or we could just put
>> multiboot, but the Multiboot loader is quite complex already, and it still
>> has room for growing.  Maybe the answer is to write a very simple Multiboot
>> loader and put that in kernel?
> 
> That's up to the user IMO. For example, suppose this kind of scenario:
> 
> - the user has a dual boot environment, say, GNU/Linux and Windows.
> - she uses GRUB installed with the GNU/Linux.
> - she has made something stupid in the GNU/Linux (e.g. rm -rf /).
> 
> In the case of GRUB Legacy, this is the end. It's just unbootable, because 
> stage 1.5 may not boot anything besides stage2.
> 
> In the case of GRUB 2, if the user has pre-loaded chainload.mod onto the 
> core.img, she can still boot the Windows.
> 
> Honestly, I am more interested in making it possible to use GRUB for setting 
> up a very robust environment. For example:
> 
> - the user installs a main OS and a rescue OS into a single machine. The 
> latter can be very compact (e.g. puppy, grml, etc.).
> - she installs another boot loader into the partition for the rescue OS.
> - she pre-loads chainload.mod in core.img.
> 
> I think the chainloader is the most realistic, because it is the smallest 
> loader, and GRUB does not need to read a filesystem, thus no filesystem 
> driver is required for loading an OS.
> 
> Every time I maintain a remote system, I feel the necessity of being prepared 
> for disasters (e.g. filesystem crashes). Rescue mode is one of the tools 
> required for this goal.
> 
> Regards,
> Okuji
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Move loader.c out of the kernel

[Vesa Jääskeläinen]

phcoder wrote:
> This usage case isn't the main target case. If you embed the loader
> (which tend to be quite big) then you already have an overhead from
> loader module. Why are you so concerned with overhead of boot.mod?
> But on the other hand this forces all the people in other cases to have
> boot code in core.img. I want to add preboot hooks and don't want
> increment size of kernel. multiboot.mod currently increases the size by
> around 11KB. And my patch doesn't restrict you from putting loader in
> core.img in any way

Even if you add the preboot hooks there, it should only cause size
affect in couple of bytes for uncompressed image.

Like in following "sketch":

...

preboot_handler_address: dd 0

...

cmp [preboot_handler_address], 0

je no_preboot_handler

call [preboot_handler_address]

no_preboot_handler:

Re: Move loader.c out of the kernel

[phcoder]

I was thinking about something more finished like the possibility of 
handling multiple preboot and to undo the operations in case of failed 
or returned boot. Potentially it could be moved to a separate module but 
it results in a reverse dependency and somewhat ugly code
Vesa Jääskeläinen wrote:
> phcoder wrote:
>> This usage case isn't the main target case. If you embed the loader
>> (which tend to be quite big) then you already have an overhead from
>> loader module. Why are you so concerned with overhead of boot.mod?
>> But on the other hand this forces all the people in other cases to have
>> boot code in core.img. I want to add preboot hooks and don't want
>> increment size of kernel. multiboot.mod currently increases the size by
>> around 11KB. And my patch doesn't restrict you from putting loader in
>> core.img in any way
> 
> Even if you add the preboot hooks there, it should only cause size
> affect in couple of bytes for uncompressed image.
> 
> Like in following "sketch":
> 
> ...
> 
> preboot_handler_address: dd 0
> 
> ...
> 
> cmp [preboot_handler_address], 0
> 
> je no_preboot_handler
> 
> call [preboot_handler_address]
> 
> no_preboot_handler:
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Move loader.c out of the kernel

[phcoder]

On the IRC Yoshinori K. Okuji agreed that this move can be useful in 
cases like lvm+raid and luks. Any further oppositions?
phcoder wrote:
> I was thinking about something more finished like the possibility of 
> handling multiple preboot and to undo the operations in case of failed 
> or returned boot. Potentially it could be moved to a separate module but 
> it results in a reverse dependency and somewhat ugly code
> Vesa Jääskeläinen wrote:
>> phcoder wrote:
>>> This usage case isn't the main target case. If you embed the loader
>>> (which tend to be quite big) then you already have an overhead from
>>> loader module. Why are you so concerned with overhead of boot.mod?
>>> But on the other hand this forces all the people in other cases to have
>>> boot code in core.img. I want to add preboot hooks and don't want
>>> increment size of kernel. multiboot.mod currently increases the size by
>>> around 11KB. And my patch doesn't restrict you from putting loader in
>>> core.img in any way
>>
>> Even if you add the preboot hooks there, it should only cause size
>> affect in couple of bytes for uncompressed image.
>>
>> Like in following "sketch":
>>
>> ...
>>
>> preboot_handler_address: dd 0
>>
>> ...
>>
>> cmp [preboot_handler_address], 0
>>
>> je no_preboot_handler
>>
>> call [preboot_handler_address]
>>
>> no_preboot_handler:
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
> 
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko

Re: Move loader.c out of the kernel

[phcoder]

Commited
phcoder wrote:
> On the IRC Yoshinori K. Okuji agreed that this move can be useful in 
> cases like lvm+raid and luks. Any further oppositions?
> phcoder wrote:
>> I was thinking about something more finished like the possibility of 
>> handling multiple preboot and to undo the operations in case of failed 
>> or returned boot. Potentially it could be moved to a separate module 
>> but it results in a reverse dependency and somewhat ugly code
>> Vesa Jääskeläinen wrote:
>>> phcoder wrote:
>>>> This usage case isn't the main target case. If you embed the loader
>>>> (which tend to be quite big) then you already have an overhead from
>>>> loader module. Why are you so concerned with overhead of boot.mod?
>>>> But on the other hand this forces all the people in other cases to have
>>>> boot code in core.img. I want to add preboot hooks and don't want
>>>> increment size of kernel. multiboot.mod currently increases the size by
>>>> around 11KB. And my patch doesn't restrict you from putting loader in
>>>> core.img in any way
>>>
>>> Even if you add the preboot hooks there, it should only cause size
>>> affect in couple of bytes for uncompressed image.
>>>
>>> Like in following "sketch":
>>>
>>> ...
>>>
>>> preboot_handler_address: dd 0
>>>
>>> ...
>>>
>>> cmp [preboot_handler_address], 0
>>>
>>> je no_preboot_handler
>>>
>>> call [preboot_handler_address]
>>>
>>> no_preboot_handler:
>>>
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> Grub-devel@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
> 
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko