View Single Post

   
  #7 (permalink)  
Old 02-21-2008, 12:34 PM
Aragorn
 
Posts: n/a
Default Rationale of compressed kernel images (was: Re: Strangle kernel compiling problem)

On Wednesday 28 June 2006 09:29, abelenda stood up and spoke the
following words to the masses in /alt.os.linux.gentoo...:/

> Arthur Hagen wrote:
>
>> Let me chime in with mine too -- on a system with an internal drive
>> these days, there's really no point in having a compressed kernel
>> image -- it takes slightly longer as it has to unpack, and you lose a
>> tiny bit of memory. [...]

>
> One thing, the kernel is loaded in a "special" part of the memory and
> that size is limited. Compressing the kernel is not for the sake of
> saving disk space but for it to not exceed that memory size...


This is correct. /x86/ CPU's traditionally boot up in the CPU's /real/
/mode,/ which emulates an 8086. This is a heritage from times now long
gone, which was needed for two reasons:

(1) Microsoft Windows was the most used operating environment on /x86/
architectures as of Windows 3.0, which ran on top of DOS. Later on,
Microsoft kept on marketing alleged operating systems such as Windows
95 (in various iterations), Windows 98 (in two versions) and Windows
Millenium Edition.

All of these still bootstrapped off of a DOS kernel, and DOS doesn't
recognize anything other than an /i8086/ CPU without special device
drivers that tell it that there's more memory installed than 640 KB and
that make use of this memory by switching the CPU to /protected/ /mode/
- the native mode of any 32-bit and 64-bit /x86/ CPU - to access this
memory. Windows itself - or at least, the core of it - was programmed
in DPMI, i.e. DOS Protected Mode Interface.

(2) As has been the tradition ever since Microsoft got a stronghold on
the PC market, hardware manufacturers have been adjusting to Microsoft
and Windows, rather than that the software was adjusted to the
hardware. As a result of this, the PC architecture was stuck with
legacy BIOS versions, which would always reset the CPU on boot-up, so
that it boots in /real/ /mode./

For those using other architectures and unfamiliar with the modes of the
/x86/ architecture: /real/ /mode/ is called "real" because in this
mode, the software can access the real hardware and memory addresses,
whereas in /protected/ /mode,/ only the kernel can do that, and virtual
memory is issued to userspace processes.

> That is why grub (or lilo) tells you that the kernel is too big when
> you try to boot the uncompressed one.
>
> Personnally runing linux on an ppc i don't need to worry about that
> and use a non compressed kernel which doesn't need
> loading/decompression time on boot.


That's again because of two things... ;-) First of all, the /PPC/
architecture doesn't feature a /real/ /mode/ like the /x86/ does - it's
a RISC design - and secondly, /PPC/ machines make use of an EFI BIOS.

EFI also exists for /x86/ - although it's not quite widespread there yet
- and could allow an /x86/ CPU to boot in /protected/ /mode,/ thus
skipping the loading of a compressed kernel image in /real/ /mode/ and
then switching the CPU to /protected/ /mode/ prior to decompressing the
kernel (and an eventual /initrd/ or /initramfs)./

Another advantage of an EFI BIOS is that it supports up to 128 primary
partitions per hard disk, whereas the current legacy BIOS only supports
four primary partitions, one or several of which could be extended
partition containers with logical partitions in them.

Of course, having an EFI BIOS in the machine warrants a special version
of LILO, called /ELILO./ I don't know about GRUB, but I presume that
it does or will exist in a special version for EFI as well by the time
EFI becomes mainstream on /x86./

;-)

--
With kind regards,

*Aragorn*
(Registered GNU/Linux user # 223157)
Reply With Quote