I'm trying to understand the Linux boot process:

I understand that in the (set by GRUB) first stage, the kernel (as a compressed image file) is loaded into memory and decompressed.

When control is passed to the kernel how is this actually done? Is the kernel compiled from its C source code and how is the kernel actually executed.

I have read this post, but it does not seem to answer my query:

What happens after loading the linux kernel image into RAM


Is the kernel compiled from its C source code and how is the kernel actually executed.

At this point, the kernel code is already compiled and is in a form that can be passed directly to the processor. The words compressed image file don't refer to a picture like a .JPG or .GIF file, but a memory image - a 1:1 representation (after decompression) of the actual machine code of the kernel.

In older processors, the actual instruction bytes were just fed into a hardware matrix of logic gates inside the processor called the instruction decoder: it would then enable other gates to pass on any data bytes following that particular instruction to whatever part of the processor was needed, and trigger any other necessary actions. In modern processors, there is often one more level of software control: the microcode of the processor.

When control is passed to the kernel how is this actually done?

It depends on the firmware+architecture of the system. On traditional x86 BIOS, the firmware and bootloader are usually 16-bit code that could in principle run on the very first IBM PC/AT: in there, the control is passed essentially just executing a jump instruction from the bootloader code to the kernel code, and never returning.

The first parts of the kernel code will include the decompressor routine that unpacks the rest of the kernel code, picks up any useful information the BIOS has left that would otherwise be overwritten, and switches the processor to full 32 or 64-bit mode. In this process, the bootloader code in RAM may be overwritten, and so the idea of ever returning from the kernel code back to the bootloader will become meaningless.

On modern PCs with UEFI firmware, the UEFI specification includes a standard handover protocol between the firmware/bootloader and the actual operating system, but ultimately it ends up as the processor executing a jump instruction to go from one block of code (= part of the firmware / bootloader) to another block (= the first part of the kernel) with the intention of not going back.

| improve this answer | |
  • Thank you for the detailed reply. So is this similar to when I used to write Machine Code for my ZX Spectrum, in that the assembly language was stored directly into the memory locations and run directly as machine code from there. – PeterJ Sep 28 '18 at 15:20
  • Yes, the kernel file that the bootloader loads into memory includes some header data, then a small machine code initializer/decompressor routine, and the rest is compressed data that becomes more machine code when extracted. The bootloader knows where the starting location of the initializer/decompressor routine will be (because it's either standardized or specified in the file header, depending on architecture), and it just jumps there. – telcoM Sep 28 '18 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.