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:
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.
