9. Operating System’s Design Guidelines 481
9.2 Thoughts on the Design of the Operating System: Master–Slave Mechanism
These requirements, which seem to be reasonable, hide a problem behind them: An appli- cation is a program, and an operating system is also a program, so then how can the oper- ating system organize, manage and coordinate the applications without suffering hurt from the applications?
We think it can be solved by privilege mechanism. To make sure that the operating system is capable of organizing, managing, and coordinating applications, escaping from their hurts at the same time, the most efficient way is to separate the operating system from the applications and to separate applications from applications to make sure that the operating system can’t visit applications arbitrarily, applications can’t visit the operating system, and there is no mutual visit between applications.
It means that the operating system has to make sure it can do the things listed below:
If it wants some application to run in some places of the RAM, this application will follow its order to run there. It should allocate RAM for applications that have their own clear boundaries, so that applications can’t reach out. It determines the time during which an application occupies CPU, and the application can only run within this limited time, after which the application has to return the right of CPU use to the operating system without detaining the right of CPU use privately. If some application wants to use peripherals, it can’t directly ask for peripherals; it has to ask the operating system for rights. If the operat- ing system thinks the applications can use peripherals, then it lets them use them. If the operating system doesn’t think so, then it denies its request.
Under this privilege mechanism, the relationship between operating system and application becomes a master–slave relationship. In order to remember it easily, we call this privilege mechanism the master–slave mechanism.
9.2.1 Process and Its Creation Mechanism in the Master–Slave Mechanism
9.2.1.1 Program Boundary and Process
To realize the master–slave mechanism, first of all, we should establish effective bound aries between kernel programs and applications and between applications and applications.
Most objects in real life have natural boundaries, such as houses, desks, and benches around us and ourselves. We have skin, which is our natural boundary. These natural
boundaries can effectively prevent fusion between person and person, between object and object, and between person and object, which keeps an independent and integral body and the characteristics of independence and integrity. But there are some objects in real life that don’t have natural definite boundaries, such as gasses, liquids, and so on. Because gas doesn’t have a boundary, different gases can mix easily, after which they can never be separated. If we want to hold water, the most effective way is to use containers with boundaries, such as cups and bottles.
Program codes in the computer are the same as in the cases of gasses and liquids.
They don’t have natural and definite boundaries. The operating system is required to determine boundaries artificially, which will play the role of containers that can separate and hold. Therefore designers of modern operating systems put forward the concept of process, using a “task_struct” structure to divide boundaries definitely. “Task_struct” is the main symbol of process. In terms of the operating system, process is a running pro- gram that accepts organization management and coordination of the operating system.
9.2.1.2 Process Creation
Technically, there are many ways to create process. Process creation in the Linux uses the mode of object creation. Object creation is using objects that already exist to create a new object and to use a process that already exists to create a new process, which is called the mechanism of parent and child process creation. Essentially, the most important thing when creating a process is to create “task_struct.”
It’s very easy to deduce in a contrary way in logic that the creation mechanism of a parent and child process means the initial parent process must exist independently, which is process 0. It’s easy to understand that process 0 cannot be created by the creation mech- anism of parent and child, so the operating system designers have to compile the “task_
struct” of process 0 manually. When the process was created, the creation mechanism of parent and child can use process 0 as a parent process to create a child process.
When we have a process, we get the object of organization management and coordi- nation of the master–slave mechanism.
9.2.2 How Does the Designing of Operating System Display the Master–Slave Mechanism?
The relationship between the operating system kernel and user process should be designed as a master–slave relationship in order to realize the master–slave mechanism. The operat- ing system can work stablely only if the master–slave mechanism has been realized.
The designer of an operating system uses a full set of design schemes to implement the master–slave mechanism. In terms of an operating system designer, we will analyze how the thoughts of operating system design display the master–slave mechanism in three aspects below. In the first aspect, process scheduling reflects the master–slave mechanism;
in the second aspect, RAM management reflects the master–slave mechanism; and in the third aspect, the file system reflects the master–slave mechanism.
9.2.2.1 Master–Slave Mechanism That the Operating System Reflects in Process Scheduling
When the operating system is conducting process scheduling, the ways to treat the kernel and process are entirely different. Precisely, process scheduling is operated by the kernel.
When a timer interrupt occurs, the scheduler will be triggered and will judge whether the time slice of the running process has been used up. If it has been used up, the operat- ing system begins to schedule, and the running process is suspended at once no matter whether this process has been finished, and then the operating system will schedule other processes. If it’s the kernel, the scheduler returns after judging and ensuring, and the ker- nel will go on running until the task is finished. No matter how long the kernel occupies the CPU, it’s always so, and all user processes will halt and keep waiting for the end of the kernel running. Thus, it can be seen that when the operating system gained the right of pro- cess scheduling, this right only works for its slave, process, and not for its master, kernel.
The run time that is assigned to process by Linux each time is actually several time slices. How much time assigned is determined by the operating system. And there is even no chance for process to increase the time slice. The right to use the CPU will be returned to the kernel once the time slice is used up. It’s worth noting that this return is not done in the way of negotiation or by turns, but forcibly withdrawn. If the process is finished, the operating system will withdraw the right to use CPU and not wait even though there are some time slices remaining.
If we don’t adopt a master–slave mechanism, the process schedule will be designed to hand in execute permissions to the operating system proactively and consciously. And then whether and when to hand in the right to use CPU directly depend on the design of the program of process, and the operating system can hardly control it. What is more hor- rible is that if the process is a malware program or a program with frequently exception zombie happens, the operating system will probably never withdraw the right to use CPU, which will lead to paralysis of the entire system.
The design of the master–slave mechanism ensures that the situation in which an application occupies the resources of the CPU will, at most, have a influence on the time slices assigned to it by the operating system. When these time slices are used up, execute permission will be returned to the operating system naturally, after which the operating system can deal with process and forcibly turn off a process that has failed.
Specific details of technique have been introduced in Chapter 6.
9.2.2.2 Master–Slave Mechanism That the Operating System Adopts in Memory Management
As was said previously, the most important symbol of process is the “task_struct” data structure. In a “task_struct” data structure, the boundary of process is definitely defined, and any action to cross a border that has not been permitted will be deterred. The distinct boundaries ensure that process cannot cross a border directly to visit the operating sys- tem kernel, and processes cannot visit each other directly. That is the embodiment of the master–slave mechanism.
The kernel and the user process of Linux 0.11 adopt a paging mechanism, respectively, but there are two sets of management data adopted: one set works for the kernel, and its range is the whole memory space of 0–16 M; the other sets works for the user process, and its range is limited to the space from 1 M to 16 M (space size below 1 M is for the kernel), which is shown in Figure 9.1.
It can be clearly seen from Figure 9.1 that if the system kernel code is in the kernel’s private space, process can never reach it, and the range of space that the kernel can visit includes the whole memory space. You can’t reach the place that is occupied by me, and
I can reach the place that is yours because your place is my place. It is “all over the world belongs to the king,” which inevitably results in “all the ones with land are the king’s servants!”
Besides, the user process can only deal with logic address and can’t directly use physi- cal address. When it needs to use RAM and is transformed to an actual physical address by the operating system kernel according to the second set 1–16 M management data scheme, the kernel divides the whole memory into memory blocks with same volume, namely page. When a process is running, the operating system will assign it several pages.
If the operating system assigns it more than two pages, these pages will not have to be adjacent, and in fact, they are always nonadjacent. The process doesn’t know where these pages have been assigned and how many pages. To be precise, the process doesn’t even have the feeling of paging. In the eyes of the process, it uses a continuous logic address in memory.
The process doesn’t know where it is, not to mention that it will know where other processes are, so mutual visits between processes will never happen. The kernel code is surely placed in the kernel area. From Figure 9.1, we can easily find that the kernel area is beyond the reach of process; therefore, the process can never visit the kernel. The process storage area is within the reach of the kernel; therefore the kernel can visit the memory space of the process at will. This is the typical master–slave relationship.
Specific details of technique have been introduced in Chapters 3 and 6.
9.2.2.3 Master–Slave Mechanism Is Reflected by OS File System
Applying for disk space when writing files is taken as an example here. When the user wants to write files into disks, first, it needs to apply to the kernel and describe which pro- cess it is, the volume of resource it needs, and the right for reading and writing resource.
When the kernel receives the application, it will decide whether to fulfill the application at once according to the resource occupied in disks now and the actual situation of buffer
Kernel paging area
Process paging area
Kernel area
Figure 9.1 Kernel and user process paging sketch.
area. If there are several processes applying for resources, the kernel will decide which process will gain resources first and make other processes keep waiting. The kernel will manage the sequence of the waiting queue to reach a standard that the kernel thinks to be best. If the current resource can’t fulfill the requirement, the kernel will refuse the applica- tion. It also reflects the master–slave mechanism between the kernel and the user process.
Once the work of the user process reaches the basement, it needs to apply or report to the kernel in advance because it doesn’t have the right to apply for resources directly. The ker- nel handles all sorts of hardware resources and takes charge of organization management and coordination of many processes that apply for resources.
Specific details of technique have been introduced in Chapter 5.