Slashdot Mirror

← Back to Stories (view on slashdot.org)

Anatomy of the Linux Boot Process

Posted by Zonk on from the step-one-turn-on-computer dept.

Donna writes "This article discusses detailed similarities and differences involved in booting Linux on an x86-based platform (typically a PC-compatible SBC) and a custom embedded platform based around PowerPC, ARM, and others. It discusses suggested hardware and software designs and highlights the tradeoffs of each. It also describes important design pitfalls and best practices."

3 of 170 comments (clear)

  1. What a Debian system looks like when booting by El+Cubano · · Score: 5, Interesting
    http://seehuhn.de/comp/bootlog.html

    Originally posted on the debian-devel list: http://lists.debian.org/debian-devel/2004/11/msg00 547.html

  2. Arrows by Bios_Hakr · · Score: 5, Interesting

    I really hate to nit-pick, but any editor should have caught that the arrows in the flow chart point the wrong way.

    Anyway, I've often wondered why the OS insists on redetecting hardware when BIOS does it for me already. I've heard that the LinuxBios actually does away with the hardware detect phase; leaving it solely to the kernel.

    If the most popular OSes out there are taking care of HW at the high level, why haven't BIOS makers taken advantage of this to reduce their workload?

    --
    I'd rather you do it wrong, than for me to have to do it at all.
  3. Re:Speaking of linux booting... by SEE · · Score: 4, Interesting
    Bruce Tognazzini, founder the Apple Human Interface Group and fomer Apple Human Interface Evangelist, disagrees.

    Some might be surprised to learn, however, that not only do I accept the idea of having flashing updates, such as "loading the kernel," I actually embrace it. First, it keeps the user engaged, and an engaged user is a happy user. Second, it informs. Yes, I'm aware that the only kernel most people are aware off is armed with eleven herbs and spices, but that's because no one has ever introduced them to the UNIX/LINUX kernel.

    In ancient times, before there was disk, we all used tape cassettes to store our applications. We could literally hear them as they loaded into the computer over a period of one to three minutes. (Thank heavens today's hard disks are a million times faster so that, for example, Excel can load in only a few microseconds.) One might assume the sound of a loading program would be indistinguishable from random noise, but that proved not the case. Every application and every image had a unique signature. After a while, we could tell if we'd started the wrong program just by the sound of its code.

    Today, few modem users understand handshaking protocols, but they do become used to a familiar pattern of clicks and screeches indicating normal vs. abnormal connections.

    If regular folk can come to "understand" on some level the sound of high-speed binary code, do you think they cannot absorb some lessons from being subjected to new terminology like "kernel," etc.? Such terms so often come to be useful, as when some system software programmer spits out some horrifying message like, "fatal execution of kernel." At least they won't fear their supply of fried chicken is about to be cut off.

    Entertain them. Teach them a little something, even if it seems "way over their heads." At the very least, it will keep them awake and alert.