深入理解Linux内核：设计与实现解析

需积分: 0 93 浏览量更新于2024-07-26 收藏 3.13MB PDF 举报

"Understanding the Linux Kernel" 由 Daniel P. Bovet 和 Marco Cesati 编著，由 O'Reilly 出版，旨在帮助读者深入理解Linux内核的工作机制，适用于内核开发者、代码编写者及程序开发人员。本书详细探讨了Linux内核的主要子系统，如内存管理、进程管理和硬件接口等，旨在提升读者对操作系统原理的理解，并能将其应用于实际编程中。书中的内容分为多个部分，包括前言、介绍、内存寻址、进程管理等多个章节。前言部分阐述了本书的目标读者群体、材料组织方式和书籍整体概述。作者还提供了一些背景信息，以便读者更好地理解和学习书中的概念。书中遵循一定的约定，方便读者阅读，并提供了联系方式以便读者交流。 1. 引言部分对比了Linux与其他类Unix内核的差异，讨论了Linux对硬件的依赖性，解释了不同版本的Linux及其特性。同时，本章介绍了操作系统的基本概念，如操作系统的作用，以及Unix文件系统的概览和Unix内核的概述。 2. 内存寻址章节深入讲解了内存地址的类型、硬件层面的分段和分页机制，以及Linux如何实现这些技术。这部分内容有助于读者理解Linux如何有效地管理内存，特别是在多任务环境下如何分配和交换内存。 3. 进程管理章节详细阐述了进程描述符，即每个进程的状态和属性的存储结构，以及进程切换的过程。这一章揭示了Linux如何管理并发执行的任务，确保系统资源的公平分配和高效利用。除了以上内容，本书还涵盖了其他关键主题，如中断处理、调度算法、文件系统、网络协议栈等，全方位地剖析了Linux内核的设计与实现。通过阅读本书，读者不仅可以理解Linux内核的底层工作原理，还能掌握优化代码和提高系统性能的技巧。《理解Linux内核》是一本深入浅出的教程，它将理论与实践相结合，适合所有希望深入了解Linux内核并提升自己技能的IT专业人士。通过系统的学习，读者能够更好地应对各种环境下的技术挑战，提高工作效率和生产力。

Understanding the Linux Kernel

Therefore, all commercial Unix variants run on a restricted subset of hardware

components.

With an estimated installed base of more than 12 million and growing, people who are used to

certain creature features that are standard under other operating systems are starting to expect

the same from Linux. As such, the demand on Linux developers is also increasing. Luckily,

though, Linux has evolved under the close direction of Linus over the years, to accommodate

the needs of the masses.

1.2 Hardware Dependency

Linux tries to maintain a neat distinction between hardware-dependent and hardware-

independent source code. To that end, both the arch and the include directories include nine

subdirectories corresponding to the nine hardware platforms supported. The standard names

of the platforms are:

arm

Acorn personal computers

alpha

Compaq Alpha workstations

i386

IBM-compatible personal computers based on Intel 80x86 or Intel 80x86-compatible

microprocessors

m68k

Personal computers based on Motorola MC680x0 microprocessors

mips

Workstations based on Silicon Graphics MIPS microprocessors

ppc

Workstations based on Motorola-IBM PowerPC microprocessors

sparc

Workstations based on Sun Microsystems SPARC microprocessors

sparc64

Workstations based on Sun Microsystems 64-bit Ultra SPARC microprocessors

Understanding the Linux Kernel

s390

IBM System/390 mainframes

1.3 Linux Versions

Linux distinguishes stable kernels from development kernels through a simple numbering

scheme. Each version is characterized by three numbers, separated by periods. The first two

numbers are used to identify the version; the third number identifies the release.

As shown in Figure 1-1, if the second number is even, it denotes a stable kernel; otherwise, it

denotes a development kernel. At the time of this writing, the current stable version of the

Linux kernel is 2.2.14, and the current development version is 2.3.51. The 2.2 kernel, which is

the basis for this book, was first released in January 1999, and it differs considerably from the

2.0 kernel, particularly with respect to memory management. Work on the 2.3 development

version started in May 1999.

Figure 1-1. Numbering Linux versions

New releases of a stable version come out mostly to fix bugs reported by users. The main

algorithms and data structures used to implement the kernel are left unchanged.

Development versions, on the other hand, may differ quite significantly from one another;

kernel developers are free to experiment with different solutions that occasionally lead to

drastic kernel changes. Users who rely on development versions for running applications may

experience unpleasant surprises when upgrading their kernel to a newer release. This book

concentrates on the most recent stable kernel that we had available because, among all

the new features being tried in experimental kernels, there's no way of telling which will

ultimately be accepted and what they'll look like in their final form.

At the time of this writing, Linux 2.4 has not officially come out. We tried to anticipate the

forthcoming features and the main kernel changes with respect to the 2.2 version by looking

at the Linux 2.3.99-pre8 prerelease. Linux 2.4 inherits a good deal from Linux 2.2: many

concepts, design choices, algorithms, and data structures remain the same. For that reason, we

conclude each chapter by sketching how Linux 2.4 differs from Linux 2.2 with respect to

the topics just discussed. As you'll notice, the new Linux is gleaming and shining; it should

appear more appealing to large corporations and, more generally, to the whole business

community.

Understanding the Linux Kernel

1.4 Basic Operating System Concepts

Any computer system includes a basic set of programs called the operating system. The most

important program in the set is called the kernel. It is loaded into RAM when the system boots

and contains many critical procedures that are needed for the system to operate. The other

programs are less crucial utilities; they can provide a wide variety of interactive experiences

for the user—as well as doing all the jobs the user bought the computer for—but the essential

shape and capabilities of the system are determined by the kernel. The kernel, then, is where

we fix our attention in this book. Hence, we'll often use the term "operating system" as

a synonym for "kernel."

The operating system must fulfill two main objectives:

• Interact with the hardware components servicing all low-level programmable elements

included in the hardware platform.

• Provide an execution environment to the applications that run on the computer system

(the so-called user programs).

Some operating systems allow all user programs to directly play with the hardware

components (a typical example is MS-DOS). In contrast, a Unix-like operating system hides

all low-level details concerning the physical organization of the computer from applications

run by the user. When a program wants to make use of a hardware resource, it must issue

a request to the operating system. The kernel evaluates the request and, if it chooses to grant

the resource, interacts with the relative hardware components on behalf of the user program.

In order to enforce this mechanism, modern operating systems rely on the availability of

specific hardware features that forbid user programs to directly interact with low-level

hardware components or to access arbitrary memory locations. In particular, the hardware

introduces at least two different execution modes for the CPU: a nonprivileged mode for user

programs and a privileged mode for the kernel. Unix calls these User Mode and Kernel Mode,

respectively.

In the rest of this chapter, we introduce the basic concepts that have motivated the design of

Unix over the past two decades, as well as Linux and other operating systems. While the

concepts are probably familiar to you as a Linux user, these sections try to delve into them

a bit more deeply than usual to explain the requirements they place on an operating system

kernel. These broad considerations refer to Unix-like systems, thus also to Linux. The other

chapters of this book will hopefully help you to understand the Linux kernel internals.

1.4.1 Multiuser Systems

A multiuser system is a computer that is able to concurrently and independently execute

several applications belonging to two or more users. "Concurrently" means that applications

can be active at the same time and contend for the various resources such as CPU, memory,

hard disks, and so on. "Independently" means that each application can perform its task with

no concern for what the applications of the other users are doing. Switching from one

application to another, of course, slows down each of them and affects the response time seen

by the users. Many of the complexities of modern operating system kernels, which we will

examine in this book, are present to minimize the delays enforced on each program and to

provide the user with responses that are as fast as possible.

Understanding the Linux Kernel

Multiuser operating systems must include several features:

• An authentication mechanism for verifying the user identity

• A protection mechanism against buggy user programs that could block other

applications running in the system

• A protection mechanism against malicious user programs that could interfere with, or

spy on, the activity of other users

• An accounting mechanism that limits the amount of resource units assigned to each

user

In order to ensure safe protection mechanisms, operating systems must make use of the

hardware protection associated with the CPU privileged mode. Otherwise, a user program

would be able to directly access the system circuitry and overcome the imposed bounds. Unix

is a multiuser system that enforces the hardware protection of system resources.

1.4.2 Users and Groups

In a multiuser system, each user has a private space on the machine: typically, he owns some

quota of the disk space to store files, receives private mail messages, and so on. The operating

system must ensure that the private portion of a user space is visible only to its owner. In

particular, it must ensure that no user can exploit a system application for the purpose of

violating the private space of another user.

All users are identified by a unique number called the User ID , or UID. Usually only a

restricted number of persons are allowed to make use of a computer system. When one of

these users starts a working session, the operating system asks for a login name and a

password. If the user does not input a valid pair, the system denies access. Since the password

is assumed to be secret, the user's privacy is ensured.

In order to selectively share material with other users, each user is a member of one or more

groups, which are identified by a unique number called a Group ID , or GID. Each file is also

associated with exactly one group. For example, access could be set so that the user owning

the file has read and write privileges, the group has read-only privileges, and other users on

the system are denied access to the file.

Any Unix-like operating system has a special user called root, superuser, or supervisor. The

system administrator must log in as root in order to handle user accounts, perform

maintenance tasks like system backups and program upgrades, and so on. The root user can

do almost everything, since the operating system does not apply the usual protection

mechanisms to her. In particular, the root user can access every file on the system and can

interfere with the activity of every running user program.

1.4.3 Processes

All operating systems make use of one fundamental abstraction: the process . A process can

be defined either as "an instance of a program in execution," or as the "execution context" of a

running program. In traditional operating systems, a process executes a single sequence of

instructions in an address space ; the address space is the set of memory addresses that the

process is allowed to reference. Modern operating systems allow processes with multiple

Understanding the Linux Kernel

execution flows, that is, multiple sequences of instructions executed in the same address

space.

Multiuser systems must enforce an execution environment in which several processes can be

active concurrently and contend for system resources, mainly the CPU. Systems that allow

concurrent active processes are said to be multiprogramming or multiprocessing.

[4]

It is

important to distinguish programs from processes: several processes can execute the same

program concurrently, while the same process can execute several programs sequentially.

[4]

Some multiprocessing operating systems are not multiuser; an example is Microsoft's Windows 98.

On uniprocessor systems, just one process can hold the CPU, and hence just one execution

flow can progress at a time. In general, the number of CPUs is always restricted, and therefore

only a few processes can progress at the same time. The choice of the process that can

progress is left to an operating system component called the scheduler. Some operating

systems allow only nonpreemptive processes, which means that the scheduler is invoked only

when a process voluntarily relinquishes the CPU. But processes of a multiuser system must be

preemptive ; the operating system tracks how long each process holds the CPU and

periodically activates the scheduler.

Unix is a multiprocessing operating system with preemptive processes. Indeed, the process

abstraction is really fundamental in all Unix systems. Even when no user is logged in and no

application is running, several system processes monitor the peripheral devices. In particular,

several processes listen at the system terminals waiting for user logins. When a user inputs a

identity is acknowledged, the process creates another process that runs a shell into which

commands are entered. When a graphical display is activated, one process runs the window

manager, and each window on the display is usually run by a separate process. When a user

creates a graphics shell, one process runs the graphics windows, and a second process runs the

shell into which the user can enter the commands. For each user command, the shell process

creates another process that executes the corresponding program.

Unix-like operating systems adopt a process/kernel model. Each process has the illusion that

it's the only process on the machine and it has exclusive access to the operating system

services. Whenever a process makes a system call (i.e., a request to the kernel), the hardware

changes the privilege mode from User Mode to Kernel Mode, and the process starts the

execution of a kernel procedure with a strictly limited purpose. In this way, the operating

system acts within the execution context of the process in order to satisfy its request.

Whenever the request is fully satisfied, the kernel procedure forces the hardware to return to

User Mode and the process continues its execution from the instruction following the system

call.

1.4.4 Kernel Architecture

As stated before, most Unix kernels are monolithic: each kernel layer is integrated into the

whole kernel program and runs in Kernel Mode on behalf of the current process. In contrast,

microkernel operating systems demand a very small set of functions from the kernel,

generally including a few synchronization primitives, a simple scheduler, and an interprocess

communication mechanism. Several system processes that run on top of the microkernel

implement other operating system-layer functions, like memory allocators, device drivers,

system call handlers, and so on.

剩余541页未读，继续阅读

gaozon

粉丝: 0
资源: 1

深入理解Linux内核：设计与实现解析

understanding the linux kernel

Understanding Linux Kernel

Understanding The Linux Kernel

Understanding the LINUX Kernel

Understanding The Linux Kernel 3rd

Understanding the Linux Kernel 3rd

understanding the linux kernel 3

Understanding the Linux Kernel pdf

understanding linux kernel 中文版,Understanding the Linux Kernel [PDF]

2009-2023年上市公司企业客户ESG数据-最新出炉.zip

最新资源