MIT xv6：一款开源教学操作系统详析

操作系统

需积分: 14 5 浏览量更新于2024-07-17 收藏 1.06MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

《麻省理工学院操作系统课程XV6教程》是一份针对操作系统入门者设计的优秀教材，由 Russ Cox、Frans Kaashoek 和 Robert Morris 联合开发。该教程的核心是基于Dennis Ritchie和Ken Thompson在Unix Version 6（v6）上的工作，对现代操作系统原理进行深入讲解。XV6选择用ANSIC语言重新实现，并针对x86架构的多处理器环境进行了优化，旨在通过实践与理论相结合的方式教授学生。本教程内容分为多个部分： 1. **操作系统接口**：这部分介绍了操作系统如何与用户程序交互，包括标准输入输出、系统调用等，帮助读者理解操作系统如何作为计算机硬件和应用程序之间的桥梁。 2. **操作系统组织**：涵盖了操作系统的基本结构，如内核与用户空间的划分，以及核心组件如进程管理、内存管理和设备驱动程序的设计。 3. **页表与内存管理**：这部分讨论了虚拟内存的概念，以及如何通过页表来映射物理内存，保证程序的独立执行和数据保护。 4. **陷阱、中断和驱动程序**：深入探讨了中断处理机制，以及如何编写和管理硬件设备的驱动程序，使系统能够响应硬件事件并完成相关操作。 5. **同步与锁定**：讲解了并发控制的机制，如互斥锁、信号量等，以确保多任务环境下的数据一致性。 6. **调度**：阐述了操作系统如何决定哪个进程或线程应该获得CPU时间片，以及不同的调度算法对性能的影响。 7. **文件系统**：讲解了文件的存储和管理，包括目录结构、文件打开、读写和关闭操作，以及文件权限和磁盘I/O的实现。 8. **总结**：对整个课程的核心概念进行回顾和提炼，帮助学生巩固所学知识。附录提供了实用信息，如： - A. 详细解释了XV6支持的硬件平台特性。 - B. **引导加载器**：介绍操作系统启动过程中的关键步骤，包括引导阶段的代码执行和系统初始化。 - 参考资料和在线资源链接，便于学生进一步探索和深入学习。《麻省理工学院操作系统XV6教程》是一个极具实践价值的学习工具，它不仅包含了丰富的理论知识，还通过源代码的学习让学生亲身体验操作系统的设计与实现过程。这对于理解和掌握操作系统原理来说，无疑是一次宝贵的经历。

资源详情

资源推荐

new user commands by just adding a new user-level program. In hindsight this plan

seems obvious, but other systems designed at the time of Unix often built such com-

mands into the shell (and built the shell into the kernel).

One exception is cd, which is built into the shell (8716). cd must change the cur-

rent working directory of the shell itself. If cd were run as a regular command, then

the shell would fork a child process, the child process would run cd, and cd would

change the child’s working directory. The parent’s (i.e., the shell’s) working directory

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.

The Unix system call interface has been standardized through the Portable Oper-

ating System Interface (POSIX) standard. Xv6 is not POSIX compliant. It misses sys-

tem calls (including basic ones such as lseek), it implements systems calls only par-

tially, etc. Our main goals for xv6 are simplicity and clarity while providing a simple

UNIX-like system-call interface. Several people have extended xv6 with a few more

basic system calls and a simple C library so that they can run basic Unix programs.

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

kernel services, than xv6. For example, they support networking, windowing systems,

user-level threads, drivers for many devices, and so on. Modern kernels evolve contin-

uously and rapidly, and oﬀer many features beyond POSIX.

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 dis-

cussed above. The authors of Unix went on to build Plan 9, which applied the ‘‘re-

sources are ﬁles’’ concept to modern facilities, representing networks, graphics, and oth-

er resources as ﬁles or ﬁle trees.

The ﬁle system abstraction has been a powerful idea. Even so, there are other

models for operating system interfaces. Multics, a predecessor of Unix, abstracted ﬁle

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

interface. 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 4, 2018 16 https://pdos.csail.mit.edu/6.828/xv6

Chapter 1

Operating system organization

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

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

new processes with fork. The operating system must time-share the resources of the

computer among these processes. For example, even if there are more processes than

there are hardware processors, the operating system must ensure that all of the pro-

cesses make progress. The operating system must also arrange for isolation between

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

that don’t depend on the failed process. Complete isolation, however, is too strong,

since it should be possible for processes to interact; pipelines are an example. Thus an

operating system must fulﬁl three requirements: 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 introduces xv6’s design by tracing the cre-

ation of the ﬁrst process 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 tailored to its needs. Applications could directly interact with hardware re-

sources and use those resources in the best way for the application (e.g., to achieve

high or predictable performance). Some operating systems for embedded devices or

real-time systems are organized in this way.

The downside of this library approach is that, if there is more than one applica-

DRAFT as of September 4, 2018 17 https://pdos.csail.mit.edu/6.828/xv6

time-share

isolation

monolithic kernel

tion running, the applications must be well-behaved. For example, each application

must periodically give up the processor so that other applications can run. Such a co-

operative time-sharing scheme may be OK if all applications trust each other and have

no bugs. It’s more typical for applications to not trust each other, and to have bugs, so

one often wants stronger isolation than a cooperative scheme provides.

To achieve strong isolation it’s helpful to forbid applications from directly access-

ing sensitive hardware resources, and instead to abstract the resources into services.

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 provides the

application with the convenience of pathnames, and it allows the operating system (as

the implementor of the interface) to manage the disk.

Similarly, Unix transparently switches hardware processors among processes, sav-

ing and restoring register state as necessary, so that applications don’t have to be aware

of time sharing. This transparency allows the operating system to share processors

even if some applications are in inﬁnite loops.

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; if memory is tight, the operating sys-

tem might even store some of a process’s data on disk. Exec also provides users with

the convenience of a ﬁle system to store executable program images.

Many forms of interaction among Unix processes occur via ﬁle descriptors. Not

only do ﬁle descriptors abstract away many details (e.g. where data in a pipe or ﬁle is

stored), they also are deﬁned in a way that simpliﬁes interaction. For example, if one

application in a pipeline fails, the kernel generates end-of-ﬁle for the next process in

the pipeline.

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

provide both programmer convenience and the possibility of 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

Strong isolation requires a hard boundary between applications and the operating

system. If the application makes a mistake, we don’t want the operating system to fail

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

the failed application and continue running other applications. To achieve strong iso-

lation, the operating system must arrange that applications cannot modify (or even

read) the operating system’s data structures and instructions and that applications can-

not access other process’s memory.

Processors provide hardware support for strong isolation. For example, the x86

processor, like many other processors, has two modes in which the processor can exe-

cute instructions: kernel mode and user mode. In kernel mode the processor is allowed

to execute privileged instructions. For example, reading and writing the disk (or any

other I/O device) involves privileged instructions. If an application in user mode at-

DRAFT as of September 4, 2018 18 https://pdos.csail.mit.edu/6.828/xv6

kernel mode

user mode

privileged

instructions

tempts to execute a privileged instruction, then the processor doesn’t execute the in-

struction, 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. Figure 0-1 in Chap-

ter 0 illustrates this organization. An application can execute only user-mode instruc-

tions (e.g., adding numbers, etc.) and is said to be running in user space, while the

software in kernel mode can also execute privileged instructions and is said to be run-

ning in kernel space. The software running in kernel space (or in kernel mode) is

called the kernel.

An application that wants to read or write a ﬁle on disk 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 for transitions 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 is what part of the operating system should run in kernel

mode. One possibility is that the entire operating system resides in the kernel, so that

the implementations of all system calls run in kernel mode. This organization is called

a monolithic kernel.

In this organization the entire operating system runs with full hardware privilege.

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 operating

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 minimize the

amount of operating system code that runs in kernel mode, and execute the bulk of

the operating system in user mode. 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 process. OS services running as processes are called servers. To allow ap-

plications to interact with the ﬁle server, the kernel provides an inter-process commu-

nication mechanism to send messages from one user-mode process to another. For

DRAFT as of September 4, 2018 19 https://pdos.csail.mit.edu/6.828/xv6

user space

kernel space

kernel

monolithic kernel

microkernel

Microkernel

shell File server

user

space

kernel

space

Send message

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

microkernel

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, sending messages, accessing device hardware, etc. This organiza-

tion allows the kernel to be relatively simple, as most of the operating system resides

in user-level servers.

Xv6 is implemented as a monolithic kernel, following most Unix operating sys-

tems. Thus, in xv6, the kernel interface corresponds to the operating system interface,

and the kernel implements the complete operating system. Since xv6 doesn’t provide

many services, 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 process’s

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

itself, so that a process can’t subvert the kernel’s isolation mechanisms. The kernel

must implement the process abstraction with care because a buggy or malicious appli-

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

enforced isolation). The mechanisms used by the kernel to implement processes in-

clude the user/kernel mode ﬂag, address spaces, and time-slicing of threads.

To help enforce isolation, the process abstraction provides the illusion to a pro-

gram that it has its own private machine. A process provides a program with what ap-

pears to be a private memory system, or address space, which other processes cannot

read or write. A process also provides the program with what appears to be its own

CPU to execute the program’s instructions.

Xv6 uses page tables (which are implemented by hardware) to give each process

its own address space. The x86 page table translates (or ‘‘maps’’) a virtual address (the

address that an x86 instruction manipulates) to a physical address (an address that the

processor chip sends to main memory).

Xv6 maintains a separate page table for each process that deﬁnes that process’s

address space. As illustrated in Figure 1-2, an address space includes the process’s user

memory starting at virtual address zero. Instructions come ﬁrst, followed by global

variables, then the stack, and ﬁnally a ‘‘heap’’ area (for malloc) that the process can ex-

pand as needed.

DRAFT as of September 4, 2018 20 https://pdos.csail.mit.edu/6.828/xv6

process

address space

virtual address

physical address

user memory

剩余107页未读，继续阅读

qq_37654326

粉丝: 0
资源: 1

MIT xv6：一款开源教学操作系统详析

天津大学操作系统实习xv6代码+报告

操作系统-xv6-MIT-util

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

xv6 操作系统来阐述操作系统的概念，它提供 Unix 操作系统中的基本接口

mit6.828 xv6

mit xv6 locking

centos安装xv6

xv6 riscv源码

ubuntu安装xv6

linux安装xv6

xv6 riscv book

centos7安装xv6

在xv6中编译运行c代码

MIT6.S081 Lab环境搭建

xv6对进程控制块定义代码

lab: xv6 and unix utilities

mit6.828hw1

mit6.828hw3

mit 6.s081

MIT6.828_HW2_SHELL

最新资源