Results 1 to 7 of 7
Does anybody know the reason why the linux kernel is compressed and the decompressed on booting a linux machine. I don't know if it was always like this? But it ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 03-02-2012 #1
- Join Date
- Apr 2011
linux kernel compression/decompression ?
I don't know if it was always like this?
But it doesn't make much since.... why you would want to do that.
Essentially the complete kernel is uncompressed into memory eventually
So why the addtion step in compressing/decompressing the kernel (I would think this is just making the boot up process longer slower with little to no benift.)
I can see if you had a compressed kernel/file system that dynamically uncompressed the essential parts when needed to safe memory....etc (but this is still cutting edge since their is no easy efficient way to write to a compressed ram disk...etc not to say some day somebody may invent one but either way still kind of don't see a real use a part from being able to do it)
Plus the fact some things like IDT , GDT ,...other critical things have to be uncompressed and stay that way before an os can work.
Their way usually memory is not an issue when we have 4GB or 8GB or more of RAM to use for putting kernel into.
Hell with paging we would have up to 64GB on 32bit machine using virtual address's...way more then enough....
Last edited by sam111; 03-02-2012 at 07:16 PM.
- 03-04-2012 #2
When I was starting in Linux, it was common practice to use a rescue floppy to boot your computer in an emergency. The kernel had to be compressed because you couldn't get it onto a floppy disk otherwise and still have room for a basic filesystem and utilities.
According to Wikipedia, decompressing the kernel is a negligible factor in boot time."I'm just a little old lady; don't try to dazzle me with jargon!"
- 03-04-2012 #3
- Join Date
- Apr 2011
Ok, I see.
Didn't think of that.
Back in the old days of floppies 1.44MB or less space. (hell linux came out in the 90's far after the first cd's so even then we had enough room if we used a cd , unfortunately not many people had the cd rom at that time probably)
But seems to me compressing the kernel shouldn't be an issue now a days with the size of media HD,CD/DVD/BlueRay (and we could do with out compressing in most cases)
But then I also see for backwards compatiblity and maybe in the future or rare event when space is an issue it could still come in handy.
You say it is fast to decompress.
Curious what compression/decompression algorithm is being used this would determine how fast and what percentage of size saved in doing the compression for the linux kernel?
And from what I understand windows OS don't use this feature when loading ... i.e they don't compress the ntoskrnl.exe like linux does. (maybe why they don't, is they can use msdos os as their boot floppy disk)
And even that wouldn't be to worth it now since we have bartsPE builder to build a windows live based cd/dvd or use a linux live cd in the event of fixing something.
But I guess if it is not slowing things down and could be convinent to use on small embedded or floppy devices then this still will have applications and should be left alone.
Thanks for the idea.
Curious if their is a switch when compileing the kernel to tell it not to compress the kernel when building a linux kernel?
- 03-04-2012 #4
From Gentoo Kernel-3.2.9
The linux kernel is a kind of self-extracting executable.
Several compression algorithms are available, which differ
in efficiency, compression and decompression speed.
Compression speed is only relevant when building a kernel.
Decompression speed is relevant at each boot.
If you have any problems with bzip2 or lzma compressed
kernels, mail me (Alain Knaff) <email@example.com>. (An older
version of this functionality (bzip2 only), for 2.4, was
supplied by Christian Ludwig)
High compression options are mostly useful for users, who
are low on disk space (embedded systems), but for whom ram
size matters less.
If in doubt, select 'gzip'
Prompt: Kernel compression mode
Defined at init/Kconfig:133
Depends on: HAVE_KERNEL_GZIP [=y] || HAVE_KERNEL_BZIP2 [=y] || HAVE_KERNEL_LZMA [=y] || HAVE_KERNEL_XZ [=y] || HAVE_KERNEL_LZO [=y]
-> General setup
Selected by: (HAVE_KERNEL_GZIP [=y] || HAVE_KERNEL_BZIP2 [=y] || HAVE_KERNEL_LZMA [=y] || HAVE_KERNEL_XZ [=y] || HAVE_KERNEL_LZO [=y]) && m
- 03-04-2012 #5
- Join Date
- Apr 2011
what do you mean by yes and no.
Do you mean physically going into the code and commenting out/ changing the code to not compress or decompress. Because that can always be done with enough time.
Or is their another way to change the compression/decompression thing without modifying the code. I.E some switch in the ./configure parm=...etc or menuconfig , oldconfig
Seems to me their should be an option for that so people don't have to rewrite it in the kernel.
But then ofcourse either way is not a big deal in most cases.
But just curious if anybody knew for sure if it is possible without having to modify the code or create a custom kernel.
- 03-05-2012 #6
You asked "there is a switch when compileing the kernel to tell it not to compress the kernel". Yes, if you go into the kernel configuration (I'm using make xconfig) there is an option to change it to a different compression format but no, I don't think you can just disable it without changing the underlying source code.
- 12-07-2012 #7
- Join Date
- Dec 2012
When you compile your kernel several executables and images are produced. The one that is usually used is vmlinuz (notice the z in the end, often this file is also called bzImage). This is the compressed kernel plus the decompression code.
However there also is the vmlinux file, which is the raw uncompressed kernel. On ARM from this file another file called Image is constructed, which then is compressed and with the added decompression routines becomes the bzImage.
I cannot find this Image file on my current x86 machine, however there is a file called vmlinux.bin. If you get your bootloader to put this file at the right place in memory and jump to it, you would probably be able to boot from there.
This might also be a reason why compressed kernels are so common: The compression code is fully relocateable, so the bootloader can just load it anywhere and then have it do it's job. This code knows where it needs to put the kernel, so the bootloader may be more careless and much simpler. However the kernel image is rarely relocateable (although there is an option for this). So a bootloader would have to take more care starting an uncompressed kernel.