Hi,
First this patch isn't "release ready", but I need some help with it.
I split this up in 2 Parts because it is a little bit large (~80Kb).
The patch is for 2.4.14 Kernel Source, but it should patch well on other
Versions (at least the module loader).
This is the 2nd Part wich adds Multiboot compatibility to vmlinux, by adding a Multibootheader to
arch/i386/kernel/head.S
The Multiboot information (apm-table, memmapping....) are converted to linux
conform things, and the Memory used by the Modules is reserved with the
bootmem bitmap in
arch/i386/kernel/setup.c
The reserved data is released in
arch/i386/mm/init.c
when the Init data is released.
Then in
init/main.c
a newly created elf-object loader is called in
kernel/boot_modules.c
inserting the Modules into the kernel (this is in the 2Part of the Patch).
With this grub is capable of loading multiple modules at boot time, before
the root fs is mounted..
This can't be done with initrd, because you could on load one single initrd
Image.
Look at the "Debian Installation Disk's" for an example that this is usefull, at the moment they use 4 different kernel Images for the (i386) Installation disks, with this patch they would only need 1 kernel Image.
My question is what should I do to make this patch "clean" ?
I know that vmlinux isn't compressed and contains unused elf-sections.
And I know that the elf-loader is a simple copy,paste & "make it working" from
the insmod sources.
Tell me what you thing about it.
MfG, Christian K?nig. (and sorry for my poor English).
On Sat, Dec 08, 2001 at 02:59:18PM +0100, Christian Koenig wrote:
> The patch is for 2.4.14 Kernel Source, but it should patch well on other
> Versions (at least the module loader).
It patched 2.5.1-pre8 cleanly, except for a makefile. I'm running
2.5.1-pre8 with this patch right now.
> I know that vmlinux isn't compressed and contains unused elf-sections.
Just 'gzip -9 vmlinux' Grub will uncompress it for you.
This actually makes for a smaller file than bzImage (on
my machine, anyway).
Are the unused sections taking up space at runtime?
> Tell me what you thing about it.
It's a cool hack! I like grub's module loading mechanism
better than the initrd solution.
Unfortunately, grub doesn't run on all supported platforms.
And the multiboot specification isn't an accepted standard.
(grub docs just read like it is.....)
Richard Todd
Hi,
On Monday 10 December 2001 02:51, Richard Todd wrote:
> On Sat, Dec 08, 2001 at 02:59:18PM +0100, Christian Koenig wrote:
> > The patch is for 2.4.14 Kernel Source, but it should patch well on other
> > Versions (at least the module loader).
>
> It patched 2.5.1-pre8 cleanly, except for a makefile. I'm running
> 2.5.1-pre8 with this patch right now.
>
> > I know that vmlinux isn't compressed and contains unused elf-sections.
>
> Just 'gzip -9 vmlinux' Grub will uncompress it for you.
> This actually makes for a smaller file than bzImage (on
> my machine, anyway).
>
> Are the unused sections taking up space at runtime?
No, its only the .note & .comment section.
objcopy -R .note -R .comment -S vmlinux mImage
gzip -9 mImage
makes a very nice & small Kernel Image.
(This will always be smaller than bzImage,
because the compression / bsetup and bootsector code isn't inside the Kernel).
> > Tell me what you thing about it.
>
> It's a cool hack! I like grub's module loading mechanism
> better than the initrd solution.
:-)
>
> Unfortunately, grub doesn't run on all supported platforms.
> And the multiboot specification isn't an accepted standard.
> (grub docs just read like it is.....)
The Module loader isn't really grub specified,
at least do you know any bootloader who works on every platform
Linux supports ?
And what's wrong with the multiboot specification ?
OK it is highly i386 Specified, but it defines the minimal things a
boot-loader should do for the kernel (multiple Kernel Modules, a commandline,
a memorymap ....).
The main problem with my patch for the moment is that the code I have copied
from insmod is really ugly.
For example obj_load.c allocates memory without freeing it after an error
(i have fixed this, but i think it's only 1 of 100 memory leaks this code
have).
This works in an elf-program quiet well, but you can't do that inside the
Kernel.
Somebody with real god knowledge off elf-object files should take a look at
this
MfG, Christian K?nig.
I can not promise you that this patch work, but i can promise you i will
do my best to make it working. (Sorry for my poor English).