RISC-V架构：xv6操作系统详解与陷阱处理

需积分: 14 137 浏览量更新于2024-07-15 收藏 523KB PDF 举报

《RISC-V体系结构与 xv6 实现教程》是一本由 Russ Cox、Frans Kaashoek 和 Robert Morris 联合编著的关于操作系统设计和实现的教材，特别关注于 RISC-V 架构。该书旨在通过构建一个名为 xv6 的简单、类似 Unix 的教学操作系统，帮助读者理解操作系统的核心概念和底层机制。在本书的第1章中，作者首先介绍了操作系统接口，涵盖了进程与内存管理（包括进程创建、内存分配）、I/O 和文件描述符的概念，以及如何使用管道进行进程间通信。此外，还讲解了文件系统的基本原理，以及如何将其应用到实际操作系统的构建中，并配以练习题供学生实践。第二章探讨了操作系统组织结构，包括抽象物理资源的方式，用户模式、监督模式和系统调用之间的关系。书中详细阐述了内核的组织架构，以及 xv6 操作系统的代码结构。接着，逐步指导读者如何启动操作系统和创建第一个进程，以及这些操作背后的原理。同时，书中强调了与现实世界的关联，并提供了相应的练习来加深理解。第三章深入讨论了页面表，这是操作系统管理虚拟内存的关键。作者解释了硬件级的页表支持，以及内核和进程的地址空间管理。代码示例展示了如何创建地址空间、物理内存分配和使用 `sbrk` 函数动态调整堆栈。此外，`exec` 系统调用用于加载和执行新的程序，这部分也包含实现在内核中的实现。章节末尾同样提供实战性质的练习。第4章聚焦于陷阱和系统调用，解析 RISC-V 中的陷阱机制，以及从用户空间和内核空间引发的陷阱。如何通过代码实现系统调用的调用过程，以及处理系统调用参数的方法都被详细说明。这部分内容有助于读者理解操作系统如何处理中断和请求以完成任务切换和资源调度。《book-riscv-rev1.pdf》是一本实用的教程，通过构建和分析 xv6 这个小型操作系统，引导读者探索 RISC-V架构下操作系统的工作原理，包括进程管理、内存管理、虚拟地址空间和系统调用等核心知识点。每章都结合了理论与实践，使读者在理论学习的同时，能动手实践，提升操作系统设计和实现的能力。

int p[2];

char

argv[2];

argv[0] = "wc";

argv[1] = 0;

pipe(p);

if(fork() == 0) {

close(0);

dup(p[0]);

close(p[0]);

close(p[1]);

exec("/bin/wc", argv);

} else {

close(p[0]);

write(p[1], "hello world\n", 12);

close(p[1]);

}

The program calls pipe, which creates a new pipe and records the read and write ﬁle descriptors

in the array p. After fork, both parent and child have ﬁle descriptors referring to the pipe. The

child calls close and dup to make ﬁle descriptor zero refer to the read end of the pipe, closes the

ﬁle descriptors in p, and calls exec to run wc. When wc reads from its standard input, it reads from

the pipe. The parent closes the read side of the pipe, writes to the pipe, and then closes the write

side.

If no data is available, a read on a pipe waits for either data to be written or for all ﬁle descrip-

tors referring to the write end to be closed; in the latter case, read will return 0, just as if the end of

a data ﬁle had been reached. The fact that read blocks until it is impossible for new data to arrive

is one reason that it’s important for the child to close the write end of the pipe before executing

wc above: if one of wc ’s ﬁle descriptors referred to the write end of the pipe, wc would never see

end-of-ﬁle.

The xv6 shell implements pipelines such as grep fork sh.c | wc -l in a manner similar

to the above code (user/sh.c:100). The child process creates a pipe to connect the left end of the

pipeline with the right end. Then it calls fork and runcmd for the left end of the pipeline and

fork and runcmd for the right end, and waits for both to ﬁnish. The right end of the pipeline

may be a command that itself includes a pipe (e.g., a | b | c), which itself forks two new child

processes (one for b and one for c). Thus, the shell may create a tree of processes. The leaves

of this tree are commands and the interior nodes are processes that wait until the left and right

children complete.

In principle, one could have the interior nodes run the left end of a pipeline, but doing so

correctly would complicate the implementation. Consider making just the following modiﬁca-

tion: change sh.c to not fork for p->left and run runcmd(p->left) in the interior pro-

cess. Then, for example, echo hi | wc won’t produce output, because when echo hi exits

in runcmd, the interior process exits and never calls fork to run the right end of the pipe. This

incorrect behavior could be ﬁxed by not calling exit in runcmd for interior processes, but this

ﬁx complicates the code: now runcmd needs to know if it a interior process or not. Complications

also arise when not forking for runcmd(p->right). For example, with just that modiﬁcation,

sleep 10 | echo hi will immediately print “hi” instead of after 10 seconds, because echo

runs immediately and exits, not waiting for sleep to ﬁnish. Since the goal of the sh.c is to be as

simple as possible, it doesn’t try to avoid creating interior processes.

Pipes may seem no more powerful than temporary ﬁles: the pipeline

echo hello world | wc

could be implemented without pipes as

echo hello world >/tmp/xyz; wc </tmp/xyz

Pipes have at least four advantages over temporary ﬁles in this situation. First, pipes automatically

clean themselves up; with the ﬁle redirection, a shell would have to be careful to remove /tmp/xyz

when done. Second, pipes can pass arbitrarily long streams of data, while ﬁle redirection requires

enough free space on disk to store all the data. Third, pipes allow for parallel execution of pipeline

stages, while the ﬁle approach requires the ﬁrst program to ﬁnish before the second starts. Fourth,

if you are implementing inter-process communication, pipes’ blocking reads and writes are more

efﬁcient than the non-blocking semantics of ﬁles.

1.4 File system

The xv6 ﬁle system provides data ﬁles, which contain uninterpreted byte arrays, and directories,

which contain named references to data ﬁles and other directories. The directories form a tree,

starting at a special directory called the root. A path like /a/b/c refers to the ﬁle or directory

named c inside the directory named b inside the directory named a in the root directory /. Paths

that don’t begin with / are evaluated relative to the calling process’s current directory, which can

be changed with the chdir system call. Both these code fragments open the same ﬁle (assuming

all the directories involved exist):

chdir("/a");

chdir("b");

open("c", O_RDONLY);

open("/a/b/c", O_RDONLY);

The ﬁrst fragment changes the process’s current directory to /a/b; the second neither refers to nor

changes the process’s current directory.

There are system calls to create new ﬁles and directories: mkdir creates a new directory, open

with the O_CREATE ﬂag creates a new data ﬁle, and mknod creates a new device ﬁle. This example

illustrates all three:

mkdir("/dir");

fd = open("/dir/file", O_CREATE|O_WRONLY);

close(fd);

mknod("/console", 1, 1);

Mknod creates a special ﬁle that refers to a device. Associated with a device ﬁle are the major and

minor device numbers (the two arguments to mknod), which uniquely identify a kernel device.

When a process later opens a device ﬁle, the kernel diverts read and write system calls to the

kernel device implementation instead of passing them to the ﬁle system.

A ﬁle’s name is distinct from the ﬁle itself; the same underlying ﬁle, called an inode, can have

multiple names, called links. Each link consists of an entry in a directory; the entry contains a ﬁle

name and a reference to an inode. An inode holds metadata about a ﬁle, including its type (ﬁle or

directory or device), its length, the location of the ﬁle’s content on disk, and the number of links to

a ﬁle.

The fstat system call retrieves information from the inode that a ﬁle descriptor refers to. It

ﬁlls in a struct stat, deﬁned in stat.h (kernel/stat.h) as:

#define T_DIR 1 // Directory

#define T_FILE 2 // File

#define T_DEVICE 3 // Device

struct stat {

int dev; // File system’s disk device

uint ino; // Inode number

short type; // Type of file

short nlink; // Number of links to file

uint64 size; // Size of file in bytes

};

The link system call creates another ﬁle system name referring to the same inode as an exist-

ing ﬁle. This fragment creates a new ﬁle named both a and b.

open("a", O_CREATE|O_WRONLY);

link("a", "b");

Reading from or writing to a is the same as reading from or writing to b. Each inode is identiﬁed

by a unique inode number. After the code sequence above, it is possible to determine that a and b

refer to the same underlying contents by inspecting the result of fstat: both will return the same

inode number (ino), and the nlink count will be set to 2.

The unlink system call removes a name from the ﬁle system. The ﬁle’s inode and the disk

space holding its content are only freed when the ﬁle’s link count is zero and no ﬁle descriptors

refer to it. Thus adding

unlink("a");

to the last code sequence leaves the inode and ﬁle content accessible as b. Furthermore,

fd = open("/tmp/xyz", O_CREATE|O_RDWR);

unlink("/tmp/xyz");

is an idiomatic way to create a temporary inode with no name that will be cleaned up when the

process closes fd or exits.

Unix provides ﬁle utilities callable from the shell as user-level programs, for example mkdir,

ln, and rm. This design allows anyone to extend the command-line interface by adding new user-

level programs. In hindsight this plan seems obvious, but other systems designed at the time of

Unix often built such commands into the shell (and built the shell into the kernel).

One exception is cd, which is built into the shell (user/sh.c:160). cd must change the current

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.

1.5 Real world

Unix’s combination of “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

culture of “software tools” that was responsible 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 Operating System

Interface (POSIX) standard. Xv6 is not POSIX compliant: it is missing many system calls (in-

cluding basic ones such as lseek), and many of the system calls it does provide differ from the

standard. 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 system calls and a sim-

ple C library in order to 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 net-

working, windowing systems, user-level threads, drivers for many devices, and so on. Modern

kernels evolve continuously and rapidly, and offer many features beyond POSIX.

Unix uniﬁed access to multiple types of resources (ﬁles, directories, and devices) with a single

set of ﬁle-name and ﬁle-descriptor interfaces. This idea can be extended to more kinds of resources;

a good example is Plan 9 [13], which applied the “resources are ﬁles” concept to networks, graph-

ics, and more. However, most Unix-derived operating systems have not followed this route.

The ﬁle system and ﬁle descriptors have been powerful abstractions. 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 different ﬂ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.

Xv6 does not provide a notion of users or of protecting one user from another; in Unix terms,

all xv6 processes run as root.

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 processes onto the underlying

hardware, isolate processes from each other, and provide mechanisms 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.

剩余109页未读，继续阅读

「已注销」

粉丝: 0
资源: 1

RISC-V架构：xv6操作系统详解与陷阱处理

book-riscv-rev0.pdf

xv6-book-riscv 参考资料

sil-padauk-book-fonts-3.003-1.el8.noarch.rpm

fullstack-react-book-2019.1.iso

6lowpan-book-slides-full-20091206.pdf

pcasm-book-simplified-chinese.pdf

selenium-webdriver-book-sample.pdf

dragon-book-exercise-answers-master.zip

xv6-riscv-book-Chinese

[3]ROGERS-FEB-E-Book-2018.pdf

最新资源