Thread: kernel

Last time we discussed the various types of operations and system calls. In this article, we will focus more on the literature. Like I mentioned, there are two different modes: the kernel and the user mode. Let's look at the two types of switching. The first is when you make a system call. After calling it, the task will go for codes that are operational in the kernel mode. The other case is when you deal with interrupt requests (IRQs). Soon after an IRQ, a handler is called and the control goes back to the task that was interrupted.

A system call may be used when you want to access a particular I/O device or file, or when you need to get privileged information. It may also be used when you require to execute a command or to change the execution context.

Now let me elucidate the whole process that governs an IRQ event. We'll assume
that a particular process is running. An IRQ may occur while the process is running.
Then, the task will be interrupted to call the corresponding interrupt handler and it
is executed right there. In the next step, as mentioned before, the control goes back to the task (which is running in user mode) and the process is back to its original state.

Non-free elements in the kernel

In an earlier column, I had discussed the non-free code portions in the kernel. And I received a number of queries regarding the subject. So, I think it is appropriate to discuss it here.

It is true that the kernel (from the original repository) contains non-free elements, especially hardware drivers that depend on non-free firmware. It will ask you to install additional non-free software that it doesn't contain.

In fact, there is a project (unfortunately, not very active!) involved in the process of removing software that is included without source code; say. with obfuscated or obscured source code. It is the Linux¬libre project of FSF - LA.

The interesting point is that maintaining Linux-libre is not a time-consuming process. And there are scripts that will inform the project manager whether there is anything that needs manual intervention.

David Woodhouse suggested having a separate branch of the kernel source tree (which would be excluded from a normal kernel build process) for non-free firmware. Thus, the non-free firmware could be distributed in a separate package. But the idea of 'complete freedom', as proposed by Linux-libre, is not respected here.

Outline of Linux kernel
Now let's consider the idea of tasks. We have already seen that Linux supports mUILi-lasking. Any application that runs the memory of the system and shares the system's resources may be termed as a task. And by multi-tasking, we are actually referring to the effective sharing of these resources among the tasks. Here, the system can switch from one task to another after a given timeslice time (say 10ms). This gives an impression that many tasks are handled Simultaneously.

Here are the detailed steps of the process: Let's say task1 is running and using the resources. Then, a resource request will be made that forces the system to put the taskl in the block list and choose task2 from the ready list for task switching. This is what happens when it comes to two tasks. You can extend this idea to N number of tasks by choosing a timer IRQ for the switching stage.

Having discussed these ideas, we can now go back to the sub-system structure of the operating system.

The process scheduler is employed to:
•Allow processes to create fresh copies
•Send signals to the user processes
•Manage the timer
•Select the process that can access the CPU Receive interrupts and route them to the appropriate kernel subsystem
•Clean up process resources (final stage of the process)

There are two types of interfaces for this-a complete interface for the kernel system and a limited one for user processes. A process can initiate other processes by copying the existing process. For example, when the system is booting, only init will be running. Then thefork() system call is used to spawn off copies. This means that it creates a new child that is a true copy of its parent.

You can see that the process scheduler is also vital for loading, execution, and the proper termination of the user processes.

The structure task_struct is used to refer a task. You can find a field that is used to indicate the state. That may have any of the following states: ready, waiting, running, returning from a system call, processing the INT routine and processing SC. You can also find fields that carry information about the clock interval and priority. From this, process ID information can be retrieved. If you take a look at the files_struct (which is a substructure), you can see the list of files opened by the process. Fields concerning the amount of time the process has spent, can also be located.

Now we can discuss the aspects concerning memory management. Here are a few of the main points concerning the unique features:
•A large pool of address space (so that user programs can refer more memory than the physically available one).
•Memory for a process is private and it cannot be modified by another process. The memory manager restricts processes from overwriting code and any read-only data.
•The memory-mapping feature can map a file into a portion of virtual memory and access the file as memory.
•The Fair Access to Physical Memory feature offers good system performance.
•The memory manager allows processes to share portions of their memory.

The memory manager offers two interfaces-a system-call interface that's used by user processes and another interface used by the kernel subsystems to perform their actions. Please see the sidebox titled 'System-call interface' for a detailed review.

Filesystem

We have already seen that Linux has been ported to various platforms ranging from computers to wristwatches. We know that even for one particular device, say a hard drive, there are many differences in the interfaces used by different vendors. Linux supports a large number oflogical filesystems. Thus, inter-operations are made possible. The filesystem has the following advantages:
•Supports multiple hardware devices
•Supports multiple logical filesystems
•Supports multiple executable formats Offers a common interface to the logical filesystems
•Provides high-speed access to files
•Can restrict a user's access to files and the user's total file size, with quotas
There are two levels of interfaces here-a system-call interface for the user processes ariq an internal interface for other kernel subsystems. File subsystems expose the data structures and the implementation function for the direct manipulation by other kernel subsystems. You may note that two interfaces are exposed, viz., inodes and files. Please glance at the box for more information.
We have reached the end of today's voyage. I look forward to your feedback so that I can incorporate your ideas into our next voyage.
Happy kernel hacking!