[WARNINGS] link-id not found - [fmiosacomparativestudypartikernellandchapter1bootup|1 link-id not found - [fmiosacomparativestudypartikernellandchapter3scheduling|3 link-id not found - [fmiosacomparativestudypartikernellandchapter5memorymanagement|5 link-id not found - [fmiosacomparativestudypartikernellandchapter7deadlocks|7 link-id not found - [fmiosacomparativestudypartiiuserlandchapter8iolayers|8 link-id not found - [fmiosacomparativestudypartiiuserlandchapter10environmentlayer|10
Intro (I 1 2 3 4 5 6 7) (II 8 9 10 11) (D) (C) (B
I)
h1. Chapter 1: Bootup
(Kickin' the tires)
Computers spring to life in many different ways. The most commonly used platform is the i386 processor series (also the primary machine on which we, the FMI/OS development team, are writing our first version); so the boot-up procedure I will recap will be for this platform.
h2. 1. BIOS
The Basic Input Output System (BIOS) is the first stop for a typical i386 bootup. This memory holds basic I/O software such as procedures for reading from the keyboard, writing to the screen and writing to the disk. The BIOS first scans all the hardware. Legacy devices (typically plugged into the ISA slots inside the computer) have their own fixed interrupts and I/O addresses, and the BIOS records these. Then, the BIOS scans all the PCI Plug-n-Play devices and assigns them interrupts and I/O addresses. These BIOS-assigned interrupts and addresses are only tentative and the OS can change them as it pleases.
This is an ideal place to make a quick mention on what are interrupts. These are some of the keys when dealing with ways that the outside world communicates with the software. For instance, a program can be running, doing its own thing, with no contact with the environment outside of the computer. Events occurring outside the computer are typically unpredictable with respect to time and order of occurrence. So, when something does happen, such as a keyboard touch, a diskette-load, or an Internet connect, the interacting hardware generates a physical "interrupt" to the processor. At this point, software within the kernel must respond to this specific event. The details of how these are handled are covered in Chapter 3, Section 1.
After this initial hardware scan and gathering, the BIOS then checks which device contains the boot information. This could be a floppy disk, CD-ROM, or, typically, the primary hard drive. The first sector (bootsector) is read. The small program in this area reads a partition table that is kept at the end of the sector. This table has all of the hard drives, their partitions, and their purpose, listed. The one it looks for, specifically, is the one designated as the boot partition. Then, this little program turns over control to another program, called the bootloader, loading it from that boot partition and subsequently running it.
This bootloader is where things really start getting interesting, especially when it comes to the operating system. This is also where the first significant difference between monolithic kernels (such as UNIX and Linux) and microkernels arises.
h2. 2. Linux
For Linux, the bootloader must access a saved configuration file as well as the kernel. To do this it must have its own built-in hard disk and filesystem drivers. With these it locates the configuration file and the kernel, also on the boot partition. Once the bootloader locates these, it loads the kernel into memory and runs it according to specialized settings mentioned in the configuration file.
The kernel does a preliminary CPU and RAM scan to know what it has to work with and then sets up all of its own memory: for the kernel stack, debug messages, data structures, etc ([[FMIOSAComparativeStudyPartIKernelLandChapter5MemoryManagement|Chapter 5]) After this Linux then begins its autoconfiguration where it sets up all of the IO devices It gets the data from the system as far as which devices are installed and what their interrupts and address spaces are and does its own scan to those devices building its own table of what is installed Linux then steps through this new table of installed devices and loads the appropriate driver to be able to speak to the device ([wikiFMIOSAComparativeStudyPartIIUserLandChapter9FileSystems Chapter 9]]) and poles each with a quick initialization routine.
After this painstaking hardware setup, Linux does a little further housework such as initializing the realtime clock, and mounting the root file system (Chapter 9). Then, Linux starts the creation of the first official process, called @init@. To run this, it does what it does with every other program it's about to run: sets up @init@'s stack, and then points the instruction pointer (the place marker for the processor which points to the next instruction to execute) to the beginning of @init@.
@Init@'s first job is running the initialization script to set up user level servers (such as networking services, mailserver daemons, etc.). @Init@ also creates/runs the shells (Chapter 10) which the user (and other programs) use to talk to the computer. At this point the bootup process is nearly completed, unless a Graphical User Interface (GUI), such as X Windows, is run.
Keep in mind that the outline of these steps is intentionally vague. The actual details would require many more pages of explanation. However, the Linux bootup procedure does allow for a comparison to FMI/OS boot procedure.
h2. 3. FMI/OS
To begin talking about FMI/OS's bootup procedure we look back to the bootloader. Due to FMI/OS' microkernel design, there are many things it cannot do on its own. Because of this, it requires a little more from the bootloader other than just a simple run command.
One major part of the supposed micro-kernel handicap is its inability to talk to any of the devices, such as the hard disk. This is a slight problem because the kernel needs to somehow have access to the first few programs it will run, such as disk and filesystem drivers! To avoid this chicken and egg problem the kernel takes advantage of the bootloader's built-in disk-access feature.
Stored on the same small boot partition as the bootloader's configuration file and the kernel are these few small setup and initialization programs, which the kernel will run. The bootloader, when loading the kernel into memory, also loads these small setup programs into memory and saves their begin and end addresses into a simple data structure called the multiboot header. When the bootloader surrenders its execution to the kernel, it passes along the address of the header as an argument.
The kernel reads the multiboot header, setting aside the addresses for the programs. It then takes the BIOS's hardware interrupt information and records them. Next, the kernel carves out its working memory, initializes the virtual memory management ([[FMIOSAComparativeStudyPartIKernelLandChapter5MemoryManagement|Chapter 6]) and allocates memory for the process and thread data structures ([wikiFMIOSAComparativeStudyPartIKernelLandChapter2ProcessesThreads Chapter 2]) The kernel then sets up process and thread information for the actual setup programs flags them as runnable and turns over control to the external processes ([wikiFMIOSAComparativeStudyPartIKernelLandChapter3Scheduling Chapter 3]]).
One of these setup programs creates a lookup table for service names; another is the device driver for the hard drive; one is the filesystem driver; and the last one is the famous @init@. Although they can be loaded in any order, their execution still happens in a predetermined sequence because each will wait, or block (Chapter 3), until the one it needs is ready. For instance, @init@ needs to be able to read off of the filesystem, so it'll block, until that program is running. However, the filesystem needs to be able to read the hard disk, but the disk needs a place to store the addresses of its service calls for others to find. So, when all of these are loaded, they start in order, like dominoes:
- @namer@ -the service lookup table
- @wd@ -the hard disk driver
- @fs@ -the filesystem driver (DOS)
- @init@ -main initialization
Whereas Linux initialized and set up all of the devices and their drivers, the root filesystem, etc., inside the kernel, FMI/OS leaves most of that up to modules outside of the kernel, in user space. This is just the first of many neat and nifty things that FMI/OS does differently that set it apart from other operating systems.
Now get ready for a description of FMI's processes and threads: the essential building blocks of activity on a computer.
Chapter 2 Processes and Threads
(c)2006 Dimitri Hammond