From The Saint (mlkong) on 13 Jul 1998 in the comp.unix.questions newsgroup
Hello Answer Guy,
I need infos on:-
There are several ways to start up a Linux kernel.
The most common is to use a package called LILO which involves using a Linux program called /sbin/lilo to read a configuration program (usually /etc/lilo.conf) and use the directives and declarations therein to build a "boot record." A LILO boot record can be written to the "master boot record" (MBR) of a hard drive, to a floppy or to a "logical boot record" (a Linux filesystem's "superblock").
Using LILO you can prompt the user for options (multi-boot and others), and even password protect specific boot modes. LILO is pretty flexible and allows one to define upto sixteen different boot configurations.
It is also possible to write a Linux kernel directly to a floppy diskette. If this is done (using a Unix/Linux command like: dd if=./kenelimage of=/dev/fd0, or using the appropriate "rawrite" commands for your OS) than the floppy will boot the kernel. However, the major limitation of this technique is that no parameters can be passed to the kernel, making it very inflexible.
Another method involves the use of the DOS program LOADLIN.EXE. I'm told there is also an NT native version of this program. LOADLIN allows you to load a Linux kernel which is stored in a normal DOS file. Once it is loaded it effectively kicks the previously loaded OS out of memory underneath it. This is very similar to the way that one loads Netware 3.x (SERVER.EXE).
LOADLIN can be called via a DOS batch file, or it can be configured as at SHELL= or INSTALL= directive in the MS-DOS CONFIG.SYS. This allows one to use the multi-boot features of MS-DOS 6.x and later to boot Linux.
LOADLIN also allows you to pass parameters to your kernels. You can have as many kernels and configurations as you can fit on your MS-DOS filesystems.
Note that the Linux kernel is not required to "be on" its root filesystem. You can use a boot record on one device to load a Linux kernel from another device which in turns mounts its root filesystem from some other device (or even from "no device" --- the kernel can have a RAM disk and use the initrd feature which we'll cover in a few more paragraphs).
It is also possible to create "El Torito" CD's for Linux. The "El Torito" format for CD's allows many of the newer systems and CD-ROM controllers to boot an OS directly off of the drive. Red Hat Inc.'s CD's have been for the last few versions (at least since 4.2 if I recall correctly). Note that this only works if your BIOS or CD-ROM controller includes the right features.
There is also a program called SYSLINUX which allows a Linux kernel to be written to an MS-DOS formatted floppy and booted therefrom. I've never used that.
On the PowerPC (Macintosh compatible systems, and others) there are different mechanisms. These systems use an "OpenBoot Firmware" which allows one to specify things like boot devices, usually through an interactive process, possibly involving a serial terminal connected to the "modem" (RS-422?) port on these systems). There are different versions of the OpenBoot firmware in different Macs and Mac clones. This can be used to boot LinuxPPC (the "monolithic" kernel). It is also possible to use a MacOS "Finder" application to boot MkLinux (the microkernel implementation of Linux for that platform).
SPARC Linux uses SILO (and all SPARC machines that I've ever heard of use OpenBoot --- or its predecessor "FCODE" --- Sun introduced and published the whole OpenBoot specification, which is essentially a small Forth kernel in ROM for doing diagnostics, booting, and device initialization and configuration). OpenBoot is used on a number of workstation platforms --- I think recent HP workstations all use it, too.
On Alphas there are a couple of different (hardware level) monitors that lead to the OS boot. I haven't played with any of them, yet, but I'm told that MILO is used on some (most?).
As we move away from the question of "how does it get into memory" we can ask what other features are unique to the Linux start-up. On unusual feature is "initrd" the option to create an "initial RAM disk image" --- this is a compressed archive that is extracted into a RAM disk, and it allows one to have a modular kernel and a script that loads the desired modules from the RAM disk. It is also possible to create multi-volume "boot/root" and "boot/init/root" sets of Linux.
I don't know what a "totally modular kernel" means. You still have the option to compile a Linux kernel with various options "built-in" and others built as separate modules. You can do this in many combinations.
With initrd you can create a kernel that doesn't even have the driver for its primary drive controllers built-in (it would be a module in the initrd image and would be auto loaded by either the "kerneld" (or "kmod") feature or by using an "insmod" or "modprobe" command from the /initrc script that's extracted unto the RAM disk).
I personally don't do this. I build my primary disk controller driver and my primary ethernet card drivers directly into my kernels.
see below.
I have no idea what a "task oriented 'splinter, splinter' tree" would be.
For your information i'm an undergraduate doing a research on this topics. Please help cause i'm in a dark over Linux operating system!!
These last two questions are far deeper into the Linux kernel code that I have gone.
You'll probably want to start by reading:
... you'll want to look at the LDP KHG (the Linux Documentation Project's Kernel Hacker's Guide) (http://sunsite.unc.edu/LDP/ and many mirrors).
You'll undoubtedly want to also extract a copy of the sources, possible for several versions of the Linux kernel, and look at the directory structures and read some of the code. That will reveal everything that's important about the organization of the kernel.
One of these days I'd like to see a "Linux Kernel Sources Annoted Study Guide" --- telling me where to start (/usr/src/linux/arch/i386/boot --- bootsect.S or setup.S?) and walks through all of the code until a simple, hypothetical system completes a shutdown. Of course it would be nice to see the video, too!
Another thing you could do is look through the archives of the kernel mailing list, even join it and read through some of the traffic that flows through there. That is the principle medium of communications for the developers who collaborate on the Linux kernel.
For comparison you might also look for overviews of the FreeBSD, NetBSD, and OpenBSD development projects.
Thanks. Email me back ASAP please...
backup | uidgid | connect | 95slow | badblock | trident | sound | |
kernel | solprint | idescsi | distrib | modem | NDS | rpm | |
guy | maildns | memleak | multihead | cdr |