I've recently learned about the boot process for Linux. I can't help but wonder why we go through the trouble of acccessing the MBR after BIOS so that instructions there can, in turn, load the kernel into RAM.
Why the middle man - why doesn't BIOS load the kernel directly?
Booting is designed to be a multi-stage process. Each stage knows just enough to load the next stage. This keeps each stage simple, and makes upgrades as painless as possible (imagine needing to re-program your BIOS when installing a new OS).
Perhaps more importantly, it keeps the whole process as platform-agnostic as possible. You can replace any step in the chain with a new platform or implementation, and the rest of the process should still work. If the BIOS loaded the OS directly, it would have to understand and be able to interpret the file system, the bootloader, the way that the OS stores components on disk, which components need to be loaded, etc. This would need to be done for each OS, filesystem, bootloader, etc. If a new filesystem (for example) is created, you wouldn't be able to use it unless you re-programmed your BIOS to understand it. Since most BIOS source code isn't publicly available, this would make developing filesystems and OSes extremely difficult.
The other thing to consider is that while it's quite possible to upgrade your BIOS to gain support for new things, that's something that people try to avoid as much as possible. If you encounter any problems when re-flashing a BIOS, you run a real chance of ending up with a broken and unrecoverable system. The easiest way to avoid needing to flash the BIOS is to keep it extremely simple, to the point where it's so generic that there's nothing that will need to be upgraded (bugfixes notwithstanding).
Because otherwise any time you used a different disk or file system you would need to rewrite the instructions in the BIOS. The MBR is an intermediary that handles that on behalf of the BIOS, knowing where to go to for the operating system.
In order for the BIOS to be able to load Linux, it would have to understand the format of its partitions and file-systems. The latter would put a lot of restrictions on the file-system that the /boot file-system may have. Therefore, to keep the BIOS minimal (the B stands for Basic :D) and let the OS evolve independently, the BIOS only loads the first 512 bytes of the boot medium.
Even though it is supposed to be "simple" in what it should do (initialize, configure and do a basic sanity test of the system), the BIOS should have at least some level of flexibility. Therefore, it was designed to:
A) Allow the user/system administrator to configure some hardware features. That's why there is a "Press DEL to enter setup" message. Generally, the defaults are optimized for your system, but some configuration options include CPU clocking, memory latency, peripheral interrupts, etc.
B) Offer a minimal basic API for some trivial stuff, like printing to the screen. This is rarely used today, as the Operating System redefines their own routines for doing the same stuff, and generally in a more specialized manner (for example the graphics driver supporting higher resolutions)
C) Boot a diverse set of operating systems from a diverse set of media (CD-ROM, USB flash, different hard-disks, etc.)
That last item is why an MBR exists. It is a standard form for listing the primary partitions on a drive (allowing multiple OSs to be present on the same drive) and what code should be executed to load and start the operating system (this code is called the boot-loader).
Anyway, at least that's why the "legacy" BIOS works the way it does. This is being slowly phased out in favor of a new initialization firmware called UEFI (at least for x86 and x86-64), which supports even more flexibility.
Finally, you can load the kernel directly. Take a look at the Coreboot project (www.coreboot.org) which does minimal initialization and then loads a payload, which could be the kernel, or it could be a standard "legacy" BIOS ;-)
Hope this helps,
Janito
