understand the linux kernel_chapter_1

Beside user process, Unix systems include a few privileged processes called kernel threads with the following characteristics:
> They run in Kernel Mode in the kernel address space.
> They do not interact with users, and thus do not require terminal devices.
> They are ususlly created during system startup and remain alive until the system is shutdown.

Unix kernels do much more than handle system calls; in fact, kernel routines can be activated in several ways:
> A process invokes a system call.
> The cpu executing the process signals an exception, which is an unusual condition such as an invalid instruction. The kernel handles the exception on behalf of the process that caused it.
> A kernel device issues an interrupt signal to the cpu to notify it of an event such as a request for attention, a status change, or the completion of an I/O operation. Each interrupt signal is dealt by a kernel program called an interrupt handler. Because peripheral devices operate asynchronously with respect to the CPU, interrputs occur at unpredictable times.
> A kernel thread is executed. Because it runs in kernel mode, the crorresponding program must be considered part of the kernel.


One way to provide reentrancy is to write functions so that they modify only local variables and do not alter golbal data structures. Such functions are called reentrant functions. But a reentrant kernel is not limited only to such functions (although that is how some real-time kernels are implemented). Instead, the kernel can include nonreentrant functions and use locking mechanisms to ensure that only one process can execute a nonreentrant functions at a time.


1.6.4
Each process runs in its private address space. A process running in User Mode refers to private stack, data, and code areas. When running in kernel Mode, the process addresses the kernel data and code areas and use another private stack.
Because the kernel is reentrant, several kernel control pathseach related to a different process may be executed in turn. In this case, each kernel control path refers to its own private kernel stack.


Processes also can share parts of their address space  as a kind of interprocess communication, using the "shared memory" technique introduced in System V and supported by Linux.

Finally, Linux supports the mmap() system call, which allows part of a file or the information stored on a block device to be mapped into a part of process address space. Memory mapping can provide an alternative to normal reads and writes for transferring data. If the same file is shared by several processes, its memory mapping is included in the address space of each of the process that share it.

1.6.5  synchroniztion and critical regions
Implementing a reentrant kernel requires the use of synchroniztion. If a kernel control path is suspended while acting on a kernel data structure, no other kernel control path should be allowed to act on the same data structure unless it has been reset to consistent state. Otherwise, the interaction of the two control paths could corrupt the stored information.

when the outcome of a computation depends on how two or more process are scheduled, the code is incorrect. We say that there is a race conditions.

Any section of code that should be finished by each process that begins it before another process can enter it is called a critical region.

1.6.5.1 kenrel preemption disabling
1.6.5.2 Interrupt disabling
1.6.5.3 Semaphores
Each semaphores may be viewed as an object composed of :
. An integer variable
. A list of waiting processes
. Two atomic methods: down() and up ()

Each data structure to be protected has its own semaphore, which is initialized to 1. When a kernel control path wishes to access the data structure, it executes the down() method on the proper semaphore. If the value of new semaphore isn't negative, access to the data structure is granted. Otherwise, the process that is executing the kernel control path is added to the semaphore list and blocked. When another process executes the up() method on that semaphore, one of the process in the semaphore list is allowed to proeceed.

1.6.5.4 Spin lock
In multiprocessor systems, semaphore are not always the bese solution to the synchronization problems. Some kernel data structures should be procted from being concurrently accessed be kernel control paths that run on different cpus. In this case, if the time required to update the data structure is short, a semsphore could be very inefficient. To check a semaphore, the kernel must insert a process in the semaphore list and then suspend it. Because both operations are relatively expensive, in the time it takes to complete them, the other kernel path could have already released the semaphore.

In these cases, multiprocessor operating systems use spin locks. A spin lock is very similar to a semphore, but it has no process list; when a process finds the lock cloesed by another process, it "spins" around repeatedly, executing a tight instruction loop until the lock becomes open.

Of course, spin locks are useless in a uniprocessor environment.

1.6.8.2  Random access memory usage
A few megabytes are dedicated to storing the kernel image(i.e. the kernel code and the kernel static data structures). The remaining portion of Ram is usually handled by the virtual memory system and is used in the three possible ways:
> To satisfy kernel requests for buffers, descriptors, and other dynamic kernel data sturctures
> To satisfy process requests for generic memory areas and for memory mapping of files
> To get better performace from disks and other buffered devices by means of caches.