Wednesday, June 25, 2008

The OS, The Kernel and The Modules

Typically kernel literature start with the words like modules, microkernels etc. Lets quickly run over these to set the context right for reading.

Often the terms operating system and kernel are confused because the two terms are used interchangeably in many books. But actually there is a difference: kernel is just one part of operating system, other parts being device drivers, user interface etc. Kernel is the innermost layer and UI is the outermost layer of an operating system. For example, command shell is a part of operating system, not of kernel. When the ls command is fired on the shell, it invokes kernel routines to read the contents of a particular directory. The kernel manages all the data structures and functions which are needed by the operating system (and the applications running on it) for several purposes. For another example, bootstrap loader is a part of operating system, which loads the kernel into RAM at the system startup. Applications such as web browser or document viewer are NOT part of operating system, however they are installed by default with many operating systems (ms-windows, red hat).

The kernel as described in Linux Kernel Development by Robert Love is as follows. "The kernel is the core internals of the operating system; the software that provides "basic services" for all other parts of the system, manages hardware, and distributes system resources. Typical components of a kernel are interrupt handlers to service interrupt requests, a scheduler to share processor time among multiple processes, a memory management system to manage process address spaces, and system services such as networking and interprocess communication."

So now we know, that the core functionality of an operating system is provided by its kernel.

Now what are modules when we talk about linux kernel? Before understanding the concept of the module, one needs to understand that by design, linux is a monolithic kernel. A monolithic kernel is implemented as a single large process. It loads into memory as a whole, executing everything in kernel mode.
The another category is microkernel architecture, in which the kernel only includes core essential functionality like inter-process communication, process scheduling, synchronization (the term microkernel: minimal kernel). The services such as memory management, device drivers are run as separate processes, which run in user space on top of the microkernel.

Compare the two architectures:
  • Monolithic kernels give great performance, with simple design, having trivial communication within the kernel (direct function calls as in a single program). But the problem with this design is that one small failure in any part of the code brings the entire system down.
  • Microkernel architectures propose clean interfaces, hardware independence, and better memory management because everything is implemented as separate components. This also makes development easy. Moreover, in case of a problem, only the specific component fails, other parts function properly. But the problem is that communication within the kernel is done by means of message passing, which makes the performance very poor.
The concept of module fits somewhere between these two kernel designs. In order to achieve advantages of microkernel architecture, offering monolithic performance at the same time, the linux kernel divides its services into modules. Different filesystems, device drivers, memory management etc are separate modules which can be inserted or removed from kernel at run time, i.e. without even having to compile the kernel. For example, ext3, vfat filesystems are inserted into the kernel as modules. After inserting into the kernel, the module becomes a part of the kernel and executes in kernel mode like other kernel routines. (While in microkernel design, it would execute as a separate process in user mode).
Try shell command lsmod to list down all the modules currently linked into the kernel.
The feature of modules in linux kernel offers a great flexibility to linux programmers and independent hackers to develop their own modules with their customized functionalities. For learners, experimenting with the kernel becomes as easy as wiriting a normal C code. If there were no modules, even for a smallest addition/experiment, one would have to make changes directly into main kernel code. Modules give us freedom to develop the kernel even without touching the kernel. Thats one of the greatest opportunities Linux has given to the kernel freaks.

Thats all the theory before starting kernel programming. From now on, only practicals. In the next post, I shall tell how did I write a small, useless module and run it in the kernel. Stay Tuned!!

References:
  1. The Tanenbaum-Torvalds Debate.
  2. The Linux Kernel Module Programming Guide.

Thursday, June 19, 2008

Wish Me Luck...

The Linux kernel is such a nice example of a well defined, cleanly interfaced, layered, modular designed system software. One may look at the kernel code to see how object oriented-ness is realized in C programming, a language which does not directly support this feature.

The subject of linux kernel is so deep and vast but equally interesting. For a beginner like me, it opens windows of excitement, wonder as well as confusion. I am trying to peep through these several windows opened before me through this blog. Ofcourse, the best way to learn something is to explain while you learn. Thats how this baby step, this blog came. This is not a tutorial or a lesson to understand the linux kernel, for surely I am not the right person for that. The intention is to better understand the internals of linux kernel in general, both for myself and the readers, by sharing the problems, confusions and discussing issues in experimenting with kernel. Writting here helps me arrange my concepts and learning in shape and evoke the thinking process. What I write here can be helpful to another beginner, whoever wants to learn the subject.

For everything, readers are cordially invited to criticize, constructively or destructively-- anyhow they want to, so that the learning is facilitated. Please bang me hard if you find even a minutest error, dont leave it just like that, for this can be helpful to many people.

Sometimes, some lines from the references might be used verbatim, when I feel I am unable to state things clearly in my words. I shall always list down the specific references used for writting the posts. However, the following three references (books) are the ones which are mostly used. Reader should prefer these for detailed description on any related topic.
  1. Linux Kernel Development By Robert Love, 2nd edition, Sams Publishing
  2. Understanding the Linux Kernel By Daniel P. Bovet, Marco Cesati, 3rd edition, O'Reilly Press
  3. Linux Device Drivers By Jonathan Corbet, Greg Kroah-Hartman, Alessandro Rubini, 3rd edition, O'Reilly Press
As the case with the above books, the posts in this blog shall be based on experience with linux kernel 2.6.x.