xv6: 一个简单的Unix-like教学操作系统

操作系统

需积分: 10 166 浏览量更新于2024-07-15 收藏 1007KB PDF 举报

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

领优惠券(最高得80元）

"这是一本关于简单Unix-like教学操作系统的书籍，名为‘xv6-rev8’，由Russ Cox、Frans Kaashoek和Robert Morris编写。该书旨在通过研究一个名为xv6的内核来解释操作系统的主要概念。xv6是对Dennis Ritchie和Ken Thompson的Unix Version 6 (v6)的操作系统重新实现，采用ANSI C语言在x86架构的多处理器上实现，虽然结构和风格上与v6类似，但有所简化。这本书的阅读应该伴随着xv6的源代码一起进行，学习方式类似于John Lions对UNIX 6th Edition的注解。" 以下是关于这个资源的详细知识点： 1. **操作系统接口**：这部分内容将介绍操作系统提供给用户和应用程序的接口，包括系统调用、命令行界面以及相关的程序开发工具。用户通过这些接口与操作系统交互，执行任务、管理文件等。 2. **操作系统组织**：这里会讨论操作系统的核心组件和它们如何协同工作，如进程管理、内存管理、设备驱动和文件系统等。还会涉及进程间的通信机制和系统服务的层次结构。 3. **页表**：页表是操作系统内存管理的关键部分，用于虚拟地址到物理地址的映射。这部分将深入解释页表的工作原理、分页系统、页面替换算法和内存保护机制。 4. **陷阱、中断和驱动程序**：这部分内容涵盖处理硬件事件（如中断）和软件异常（如陷阱）的方法。还将讨论驱动程序如何作为操作系统和硬件之间的接口，控制和管理硬件设备。 5. **锁定**：在多线程和多处理器环境中，锁定机制是保证数据一致性的重要手段。这部分会介绍各种锁机制，如互斥量、信号量、条件变量等，并讨论其在并发控制中的应用。 6. **调度**：调度是操作系统核心功能之一，负责决定哪个进程或线程应该获得CPU执行权。这部分将详细讲解调度策略，如先来先服务、短作业优先、时间片轮转等，并讨论调度的影响因素。 7. **文件系统**：文件系统是操作系统管理和组织数据的主要方式。这部分将介绍文件的存储、索引节点、目录结构、文件权限和访问控制，以及文件系统的挂载和卸载。 8. **硬件概览**（PChardware）：这部分可能会涉及个人计算机的硬件组件，如处理器、内存、磁盘和I/O设备，以及它们如何与操作系统交互。 9. **引导加载器**（The bootloader）：引导加载器是系统启动时运行的第一个程序，负责加载操作系统到内存并启动其执行。这部分会解释引导过程和引导加载器的实现。 10. **索引**：书末的索引提供了快速查找特定主题的参考，方便读者查阅。这本书是学习操作系统原理和实现的宝贵资源，通过实例xv6的分析，使得复杂的操作系统概念变得更加直观和易于理解。对于计算机科学的学生和教师，以及对操作系统感兴趣的开发者来说，都是极好的学习材料。

资源详情

资源推荐

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页未读，继续阅读

处女座程序员的朋友

粉丝: 347
资源: 104

xv6: 一个简单的Unix-like教学操作系统

XV6, a simple, Unix-like teaching operating system

pip install -i https://pypi.tuna.tsinghua.edu.cn/simple --trusted-host pypi.tuna.tsinghua.edu.cn numpy

pip install torch==1.13.1 torchvision==0.14.1 torchaudio==0.13.1 -i http://mirrors.tencentyun.com/pypi/simple --trusted-host mirrors.tencentyun.com

请解释这条python语句 pip install -i https://pypi.tuna.tsinghua.edu.cn/simple --trusted-host pypi.tuna.tsinghua.edu.cn numpy

-i http://pypi.douban.com/simple/ --trusted-host=pypi.douban.com/simple

File "<stdin>", line 1 pip install openpylx -i http://pypi.douban.com、simple --trusted-host pypi.douban.com

pip install --usel --upgrade tensorflow -i http://mirrors.aliyun.com/pypi/simple/ --trusted-host mirrors.aliyun.comi

COPY /rtsp-simple-server/. ./又是如何

pip3 install --trusted-host 192.168.0.212 --extra-index-url \ http://192.168.0.212:2199/simple flask-framework --upgrade这条命令是什么意思

simpleitk-2.2.1-cp38-cp38-win_amd64.whl

ERROR: To modify pip, please run the following command: D:\Anaconda3\envs\beifang\python.exe -m pip install -i http://pypi.douban.com/simple/ pip -U --trusted-host pypi.douban.com --user

pip install pyyaml -i http://pypi.douban.com/simple/ --trusted-host pypi.douban.com

pip3 install pytest-rerunfailures -i http://pypi.douban.com/simple/ --trusted-host pypi.douban.com

perl-IPC-System-Simple

install -r requirements_win.txt -i https://pypi.tuna.tsinghua.edu.cn/simple/ --trusted-host https://pypi.tuna.tsinghua.edu.cn 换成conda的指令

class NeuralNet(nn.Module): ''' A simple fully-connected deep neural network '''

最新资源