![](https://csdnimg.cn/release/download_crawler_static/11018312/bg10.jpg)
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’’ file 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 first 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 offer 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 files, like the console device file dis-
cussed above. The authors of Unix went on to build Plan 9, which applied the ‘‘re-
sources are files’’ concept to modern facilities, representing networks, graphics, and oth-
er resources as files or file trees.
The file system abstraction has been a powerful idea. Even so, there are other
models for operating system interfaces. Multics, a predecessor of Unix, abstracted file
storage in a way that made it look like memory, producing a very different flavor of
interface. The complexity of the Multics design had a direct influence 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