Re: [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3

[Vivek Goyal]

On Mon, Feb 05, 2007 at 04:37:43PM -0800, H. Peter Anvin wrote:
> First of all, if sending attached patches, *MAKE SURE* they're text/plain.
> 
> >diff -uprN -X linux-2.6.20/Documentation/dontdiff 
> >linux-2.6.20/arch/i386/kernel/setup.c 
> >linux-2.6.20-gujin/arch/i386/kernel/setup.c
> >--- linux-2.6.20/arch/i386/kernel/setup.c       2007-02-04 
> >18:44:54.000000000 +0000
> >+++ linux-2.6.20-gujin/arch/i386/kernel/setup.c 2007-02-05 
> >21:27:01.000000000 +0000
> >@@ -579,6 +579,19 @@ void __init setup_arch(char **cmdline_p)
> >        strlcpy(command_line, saved_command_line, COMMAND_LINE_SIZE);
> >        *cmdline_p = command_line;
> >
> >+       /*
> >+        * If the command line begin with '/', it is the filename of the
> >+        * kernel file - like a shell command line. That can be used to
> >+        * deduce where root was located when the kernel was compiled,
> >+        * inside a directory of root named /boot, inside a small partition
> >+        * mounted on a directory of root named /boot or in the root
> >+        * directory itself.
> >+        */
> >+       if (**cmdline_p == '/')
> >+               while (**cmdline_p != ' ' && **cmdline_p != '\t'
> >+                       && **cmdline_p != '\n' && **cmdline_p != '\0')
> >+                       ++*cmdline_p;
> >+
> >        max_low_pfn = setup_memory();
> >
> >        /*
> 
> The standard way to do this is to have a command line argument named 
> BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz).  There is no reason to do 
> this differently from every other bootloader.
> 
> Why build the real-mode code as part of the kernel binary?  If you have 
> to reference kernel symbols, you can do that with the -R option to ld. 
> Bundling it into the kernel binary just to then extract it later is 
> silly at best.
> 

Building real mode code with kernel binary (vmlinux) has got another
disadvantage that it breaks using vmlinux for kdump purposes. One compiles
the kernel binary to execute from a different address but real mode code/data
will continue to be at virtual/physical addr 0 and kexec can not load it
as that physical memory is not available at all. Kdump skips the real mode
code execution.

I don't know much about Gujin, but advantage here seems to be that it has
capability to load elf files and that's why the attempt to turn kernel binary
into a compressed elf image. Why don't we then simply add an ELF header to
bzImage and Gujin and any ELF loader including Gujin, should be able to load
it? (As Eric had done in one of the implementations in the past?) Why to 
create the new infrastructure?

Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/