MIT xv6 操作系统源码分析

4星 · 超过85%的资源需积分: 31 107 浏览量更新于2024-07-22 收藏 1.15MB PDF 举报

"MIT XV6 Unix第六版操作系统源码讲解" MIT XV6是一个简化的类Unix教学操作系统，由Russ Cox、Frans Kaashoek和Robert Morris编写，旨在为学生提供一个学习操作系统概念的实例。该操作系统是Dennis Ritchie和Ken Thompson的Unix Version 6 (v6)的重新实现，但在设计上保持了v6的基本结构和风格，但使用ANSI C语言针对x86架构的多处理器进行了实现。 1. 操作系统接口（Operatingsystem interfaces）这部分介绍操作系统如何提供与用户进程交互的接口，包括系统调用、进程间通信机制等。例如，XV6可能包含创建进程、终止进程、读写文件、进程同步和互斥等基本操作的系统调用。 2. 操作系统组织（Operatingsystem organization）这部分深入讨论操作系统的核心组件，如内核、进程管理、内存管理等。在XV6中，可能会涵盖进程调度、上下文切换、中断处理以及如何管理系统的各种资源。 3. 页表（Pagetables）页表是内存管理的关键部分，它将虚拟地址映射到物理地址。XV6会解释如何使用页表来实现地址空间的隔离，以及如何进行页面替换策略，确保有效使用内存。 4. 中断、陷阱和驱动程序（Traps, interrupts, and drivers）中断和陷阱是处理器处理异常情况的方式，如硬件事件或软件请求。这部分会讲述XV6如何处理这些事件，以及如何通过驱动程序与硬件设备交互，如键盘、显示器和磁盘。 5. 锁定（Locking）在多处理器环境下，锁定机制用于保证并发访问资源的安全性。XV6可能会使用自旋锁、信号量等工具来解决同步问题，确保数据一致性。 6. 调度（Scheduling）调度是决定哪个进程应该获得处理器时间的关键算法。XV6可能实现了一种简单的调度策略，如轮转调度或优先级调度，以保证公平性和响应时间。 7. 文件系统（Filesystem）文件系统管理磁盘上的数据组织和访问。XV6的文件系统可能会包括文件的创建、删除、读写操作，以及目录结构的管理。它可能会采用类似于Unix的树形结构，并实现缓存机制来提高性能。 8. 总结（Summary）这部分是对整个XV6操作系统的概述，回顾其主要的设计决策和实现细节，帮助读者巩固所学知识。 9. A节：PC硬件（PChardware）这部分可能提供了关于XV6运行的x86平台的硬件背景信息，包括处理器特性、内存系统和I/O接口。 10. B节：引导加载器（Thebootloader）引导加载器是系统启动时加载操作系统的第一部分。XV6的引导加载器会解释如何从硬盘加载内核并初始化内存。 11. 指南（Index）提供对文本中各主题的快速参考。通过阅读XV6的源代码和这个文档，学生可以了解操作系统设计的实践细节，加深对操作系统原理的理解。此外，MIT 6.828课程网站还提供了在线资源和支持，以便于深入学习和交流。

would not change.

Real world

Unix’s combination of the ‘‘standard’’ ﬁle descriptors, pipes, and convenient shell

syntax for operations on them was a major advance in writing general-purpose

reusable programs. The idea sparked a whole culture of ‘‘software tools’’ that was re-

sponsible for much of Unix’s power and popularity, and the shell was the ﬁrst so-called

‘‘scripting language.’’ The Unix system call interface persists today in systems like BSD,

Linux, and Mac OS X.

Modern kernels provide many more system calls, and many more kinds of kernel

services, than xv6. For the most part, modern Unix-derived operating systems have

not followed the early Unix model of exposing devices as special ﬁles, like the console

device ﬁle discussed above. The authors of Unix went on to build Plan 9, which ap-

plied the ‘‘resources are ﬁles’’ concept to modern facilities, representing networks,

graphics, and other resources as ﬁles or ﬁle trees.

The ﬁle system abstraction has been a powerful idea, most recently applied to

network resources in the form of the World Wide Web. Even so, there are other mod-

els for operating system interfaces. Multics, a predecessor of Unix, abstracted ﬁle stor-

age in a way that made it look like memory, producing a very diﬀerent ﬂavor of inter-

face. The complexity of the Multics design had a direct inﬂuence on the designers of

Unix, who tried to build something simpler.

This book examines how xv6 implements its Unix-like interface, but the ideas and

concepts apply to more than just Unix. Any operating system must multiplex process-

es onto the underlying hardware, isolate processes from each other, and provide mech-

anisms for controlled inter-process communication. After studying xv6, you should be

able to look at other, more complex operating systems and see the concepts underlying

xv6 in those systems as well.

DRAFT as of September 3, 2014 16 http://pdos.csail.mit.edu/6.828/xv6/

Chapter 1

Operating system organization

A key requirement for an operating system is to support several activities. For

example, using the system call interface described in chapter 0 a process can start new

processes using fork. The operating system must arrange that these processes can

time-share the resources of the computer. For example, a process may start more

new processes than there are processors in the computer, yet all processes must be able

to make some progress. In addition, the operating system must arrange for isolation

between the processes. That is, if one process has a bug and fails, it shouldn’t impact

processes that don’t have a dependency on the failed process. Complete isolation,

however, is too strong, since it should be possible for processes to interact; for example,

it is convenient for users to combine processes to perform complex tasks (e.g., by using

pipes). Thus, the implementation of an operating system must achieve three require-

ments: multiplexing, isolation, and interaction.

This chapter provides an overview of how operating systems are organized to

achieve these 3 requirements. It turns out there are many ways to do so, but this text

focuses on mainstream designs centered around a monolithic kernel, which is used

by many Unix operating systems. This chapter illustrates this organization by tracing

the ﬁrst process that is created when xv6 starts running. In doing so, the text provides

a glimpse of the implementation of all major abstractions that xv6 provides, how they

interact, and how the three requirements of multiplexing, isolation, and interaction are

met. Most of xv6 avoids special-casing the ﬁrst process, and instead reuses code that

xv6 must provide for standard operation. Subsequent chapters will explore each ab-

straction in more detail.

Xv6 runs on Intel 80386 or later (‘‘x86’’) processors on a PC platform, and much

of its low-level functionality (for example, its process implementation) is x86-speciﬁc.

This book assumes the reader has done a bit of machine-level programming on some

architecture, and will introduce x86-speciﬁc ideas as they come up. Appendix A brieﬂy

outlines the PC platform.

Abstracting physical resources

The ﬁrst question one might ask when encountering an operating system is why

have it at all? That is, one could implement the system calls in Figure 0-2 as a library,

with which applications link. In this plan, each application could even have its own li-

brary, perhaps tailored to its needs. In this plan, the application can directly interact

with the hardware resources and use those resources in the best way for the applica-

tion (e.g., to achieve high performance or predictable performance). Some tiny operat-

ing systems for embedded devices or real-time systems are organized in this way.

DRAFT as of September 3, 2014 17 http://pdos.csail.mit.edu/6.828/xv6/

time-share

isolation

monolithic kernel

The downside of this approach is that applications are free to use the library,

which means they can also not use it. If they don’t use the operating system library,

then the operating system cannot enforce time sharing. It must rely on the application

to behave properly and, for example, periodically give up a processor so that another

application can run. Such a cooperative time-sharing scheme is maybe OK for a sys-

tem where all applications trust each other, but doesn’t provide strong isolation if ap-

plications are mutually distrustful.

To achieve strong isolation a helpful approach is to disallow applications to have

direct access to the hardware resources, but instead to abstract the resources into ser-

vices. For example, applications interact with a ﬁle system only through open, read,

write, and close system calls, instead of read and writing raw disk sectors. This pro-

vides the application with the convenience of pathnames, and it allows the operating

system (as the implementor of the interface) to manage the disk.

Similarly, in Unix applications run as processes using fork, allowing the operating

system to save and restore registers on behalf of the application when switching be-

tween diﬀerent processes, so that application don’t have to be aware of process switch-

ing. Furthermore, it allows the operating system to forcefully switch an application out

of a processor, if the application, for example, is an end-less loop.

As another example, Unix processes use exec to build up their memory image,

instead of directly interacting with physical memory. This allows the operating system

to decide where to place a process in memory and move things around if there is a

shortage of memory, and provides applications with the convenience of a ﬁle system to

store their images.

To support controled interaction between applications, Unix applications can use

only ﬁle descriptors, instead of to make up some sharing convention of their own (e.g.,

reserving a piece of physical memory). Unix ﬁle descriptors abstract all the sharing

details away, hiding from the application if the interaction is happening with the ter-

minal, ﬁle system, or pipes, yet allows the operating system to control the interaction.

For example, if one application fails, it can shut down the communication channel.

As you can see, the system call interface in Figure 0-2 is carefully designed to

provide programmer convenience but also for the implementation of the interface to

enforce strong isolation. The Unix interface is not the only way to abstract resources,

but it has proven to be a very good one.

User mode, kernel mode, and system calls

To provide strong isolation between the software that uses system calls and the

software that implements the system calls, we need a hard boundary between applica-

tions and the operating system. If the application makes a mistake, we don’t want the

operating system to fail. Instead, the operating system should be able to clean up the

application and continue running other applications. This strong isolation means that

application shouldn’t be able to write over data structures maintained by the operating

system, shouldn’t be able to overwrite instructions of the operating system, etc.

To provide for such strong isolation processors provide hardware support. For

DRAFT as of September 3, 2014 18 http://pdos.csail.mit.edu/6.828/xv6/

example, the x86 processor, like many other processors, has two modes in which the

processor executes instructions: kernel mode and user mode. In kernel mode the pro-

cessor is allowed to execute privileged instructions. For example, read and writ-

ing to the disk (or any other I/O device) is a privileged instruction. If an application

in user mode attempts to execute a privileged instruction, then the processor doesn’t

execute the instruction, but switches to kernel mode so that the software in kernel

mode can clean up the application, because it did something it shouldn’t be doing. Fig-

ure 0-1 in Chapter 0 illustrates this organization. Applications can execute only user-

mode instructions (e.g., adding numbers, etc.) and is said to be running in user

space, while the software in kernel mode can execute also privileged instructions and

is said to be running in kernel space. The software running in kernel space (or in

kernel mode) is called the kernel.

If a user-mode application must read or write to disk, it must transition to the

kernel to do so, because the application itself can not execute I/O instructions. Proces-

sors provide a special instruction that switches the processor from user mode to kernel

mode and enters the kernel at an entry point speciﬁed by the kernel. (The x86 proces-

sor provides the int instruction for this purpose.) Once the processor has switched to

kernel mode, the kernel can then validate the arguments of the system call, decide

whether the application is allowed to perform the requested operation, and then deny

it or execute it. It is important that the kernel sets the entry point when transition to

kernel mode; if the application could decide the kernel entry point, a malicious appli-

cation could enter the kernel at a point where the validation of arguments etc. is

skipped.

Kernel organization

A key design question for an operating system is what part of the operating sys-

tem should run in kernel mode. A simple answer is that the kernel interface is the sys-

tem call interface. That is, fork, exec, open, close, read, write, etc. are all kernel

calls. This choice means that the complete implementation of the operating system

runs in kernel mode. This kernel organization is called a monolithic kernel.

In this organization the complete operating system runs with full hardware privi-

lege. This organization is convenient because the OS designer doesn’t have to decide

which part of the operating system doesn’t need full hardware privilege. Furthermore,

it easy for diﬀerent parts of the operating system to cooperate. For example, an oper-

ating system might have a buﬀer cache that can be shared both by the ﬁle system and

the virtual memory system.

A downside of the monolithic organization is that the interfaces between diﬀerent

parts of the operating system are often complex (as we will see in the rest of this text),

and therefore it is easy for an operating system developer to make a mistake. In a

monolithic kernel, a mistake is fatal, because an error in kernel mode will often result

in the kernel to fail. If the kernel fails, the computer stops working, and thus all appli-

cations fail too. The computer must reboot to start again.

To reduce the risk of mistakes in the kernel, OS designers can make the lines of

code that run in kernel mode small. Most of the operating system doesn’t need access

DRAFT as of September 3, 2014 19 http://pdos.csail.mit.edu/6.828/xv6/

kernel mode

user mode

privileged

instructions

user space

kernel space

kernel

monolithic kernel

Microkernel

shell File server

user

space

kernel

space

Send message

Figure 1-1. A mkernel with a ﬁle system server

microkernel

to privileged instructions, and can thus run as ordinary user-level applications, with

which applications interact with through messages. This kernel organization is called a

microkernel.

Figure 1-1 illustrates this microkernel design. In the ﬁgure, the ﬁle system runs as

a user-level application. Operating systems that services that run as ordinary user pro-

grams are called servers. To allow application to interact with the ﬁle server, the ker-

nel provides a minimal mechanism to send messages from one user-mode application

to another. For example, if an application like the shell wants to read or write a ﬁle, it

sends a message to the ﬁle server and waits for a response.

In a microkernel, the kernel interface consists of a few low-level functions for

starting applications, performing I/O, sending messages to applications, etc. This orga-

nization allows the kernel to be implemented with a few lines of code, since it doesn’t

do much, as most functionality of the operating system is implemented by user-level

servers.

In the real-world, one can ﬁnd both monolithic kernels and microkernels. For ex-

ample, Linux is mostly implemented as a monolithic kernel, although some OS func-

tions run as user-level servers (e.g., the windowing system). Xv6 is implemented as a

monolithic kernel, following most Unix operating systems. Thus, in xv6, the kernel in-

terface corresponds to the operating system interface, and the kernel implements the

complete operating system. Since xv6 doesn’t provide many functions, its kernel is

smaller than some microkernels.

Process overview

The unit of isolation in xv6 (as in other Unix operating systems) is a process.

The process abstraction prevents one process from wrecking or spying on another pro-

cess’ memory, CPU, ﬁle descriptors, etc. It also prevents a process from wrecking the

kernel itself (i.e., from preventing the kernel to enforce isolation). The kernel must

implement the process abstraction with care because a buggy or malicious application

may trick the kernel or hardware in doing something bad (e.g., circumventing enforced

isolation). The mechanisms used by the kernel to implement processes include us-

er/kernel mode ﬂag, address spaces, and time slicing of threads, which this subsection

provides an overview of.

To be able to enforce isolation, a process is an abstraction that provides the illu-

sion to a program that it has its own abstract machine. A process provides a program

DRAFT as of September 3, 2014 20 http://pdos.csail.mit.edu/6.828/xv6/

microkernel

process

剩余101页未读，继续阅读

wbin91

粉丝: 0
资源: 5

MIT xv6 操作系统源码分析

xv6-chinese_xv6_MITxv6课程实践_xv6com_

mit教学用的操作系统最新版源代码

MIT xv6&JOS;资料

mit xv6 book pdf mit xv6 unix第六版操作系统源码讲解

xv6操作系统详解：MIT教学版Unix源码分析

MIT Xv6 操作系统源码详解最新版 rev10

xv6-book-chinese：MIT操作系统工程的教学操作系统Xv6的源码剖析的翻译项目，使用ANSI标准C重新在riscv架构上实现Unix v6；

xv6-chinese:中文版的 MIT xv6 文档

xv6操作系统源代码

MIT操作系统工程的教学操作系统Xv6的源码剖析中文翻译项目.zip

最新资源