-@node Introduction, Pintos Tour, Top, Top
+@node Introduction
@chapter Introduction
Welcome to Pintos. Pintos is a simple operating system framework for
You will also add a virtual memory implementation.
Pintos could, theoretically, run on a regular IBM-compatible PC.
-Unfortunately, it is impractical to supply every CS 140 student
+Unfortunately, it is impractical to supply every @value{coursenumber} student
a dedicated PC for use with Pintos. Therefore, we will run Pintos projects
in a system simulator, that is, a program that simulates an 80@var{x}86
CPU and its peripheral devices accurately enough that unmodified operating
systems and software can run under it. In class we will use the
@uref{http://bochs.sourceforge.net, , Bochs} and
@uref{http://fabrice.bellard.free.fr/qemu/, ,
-qemu} simulators. Pintos has also been tested with
-@uref{http://www.vmware.com/products/server/gsx_features.html, ,
-VMware GSX Server}.
+QEMU} simulators. Pintos has also been tested with
+@uref{http://www.vmware.com/, , VMware Player}.
-These projects are hard. CS 140 has a reputation of taking a lot of
+These projects are hard. @value{coursenumber} has a reputation of taking a lot of
time, and deservedly so. We will do what we can to reduce the workload, such
as providing a lot of support material, but there is plenty of
hard work that needs to be done. We welcome your
@menu
* Getting Started::
* Grading::
-* License::
+* Legal and Ethical Issues::
* Acknowledgements::
* Trivia::
@end menu
@section Getting Started
To get started, you'll have to log into a machine that Pintos can be
-built on. The CS140 ``officially supported''
-Pintos development machines are the machines in Sweet Hall managed by
-Stanford ITSS, as described on the
-@uref{http://www.stanford.edu/services/cluster/environs/sweet/, , ITSS
-webpage}. You may use the Solaris or Linux machines. We will test your
-code on these machines, and the instructions given here assume this
-environment. However, Pintos and its supporting tools are portable
-enough that it should build ``out of the box'' in other environments.
+built on.
+@localmachines{}
+We will test your code on these machines, and the instructions given
+here assume this environment. We cannot provide support for installing
+and working on Pintos on your own machine, but we provide instructions
+for doing so nonetheless (@pxref{Installing Pintos}).
Once you've logged into one of these machines, either locally or
remotely, start out by adding our binaries directory to your @env{PATH}
-environment. Under @command{csh}, Stanford's login shell, you can do so
-with this command:@footnote{The term @samp{`uname -m`} expands to either
-@file{sun4u} or @file{i686} according to the type of computer you're
-logged into.}
-@example
-set path = ( $path /usr/class/cs140/`uname -m`/bin )
-@end example
-@noindent
-(Notice that both @samp{`} are left single quotes or ``backticks.'')
-It is a good idea to add this line to the @file{.cshrc} file
-in your home directory. Otherwise, you'll have to type it every time
-you log in.
+environment.
+@localpathsetup{}
@menu
* Source Tree Overview::
Now you can extract the source for Pintos into a directory named
@file{pintos/src}, by executing
@example
-tar xzf /usr/class/cs140/pintos/pintos.tar.gz
+zcat @value{localpintostarpath} | tar x
@end example
Alternatively, fetch
-@uref{http://@/www.stanford.edu/@/class/@/cs140/@/pintos/@/pintos.@/tar.gz}
+@uref{@value{localpintoshttppath}}
and extract it in a similar way.
Let's take a look at what's inside. Here's the directory structure
@item misc/
@itemx utils/
These files may come in handy if you decide to try working with Pintos
-away from the ITSS machines. Otherwise, you can ignore them.
+on your own machine. Otherwise, you can ignore them.
@end table
@node Building Pintos
@file{Makefile} and a few subdirectories, and then build the kernel
inside. The entire build should take less than 30 seconds.
-Watch the commands executed during the build. On the Linux machines,
-the ordinary system tools are used. On a SPARC machine, special build
-tools are used, whose names begin with @samp{i386-elf-}, e.g.@:
-@code{i386-elf-gcc}, @code{i386-elf-ld}. These are ``cross-compiler''
-tools. That is, the build is running on a SPARC machine (called the
-@dfn{host}), but the result will run on a simulated 80@var{x}86 machine
-(called the @dfn{target}). The @samp{i386-elf-@var{program}} tools are
-specially built for this configuration.
+@localcrossbuild{}
Following the build, the following are the interesting files in the
@file{build} directory:
Object file for the entire kernel. This is the result of linking
object files compiled from each individual kernel source file into a
single object file. It contains debug information, so you can run
-@command{gdb} or @command{backtrace} (@pxref{Backtraces}) on it.
+GDB (@pxref{GDB}) or @command{backtrace} (@pxref{Backtraces}) on it.
@item kernel.bin
Memory image of the kernel. These are the exact bytes loaded into
displayed in the terminal you used to run @command{pintos}. This is
because Pintos sends all output both to the VGA display and to the first
serial port, and by default the serial port is connected to Bochs's
-@code{stdout}. You can log this output to a file by redirecting at the
+@code{stdin} and @code{stdout}. You can log serial output to a file by
+redirecting at the
command line, e.g.@: @code{pintos run alarm-multiple > logfile}.
The @command{pintos} program offers several options for configuring the
from them by @option{--}, so that the whole command looks like
@code{pintos @var{option}@dots{} -- @var{argument}@dots{}}. Invoke
@code{pintos} without any arguments to see a list of available options.
-Options can select a simulator to use: the default is Bochs, but on the
-Linux machines @option{--qemu} selects qemu. You can run the simulator
-with a debugger (@pxref{gdb}). You can set the amount of memory to give
+Options can select a simulator to use: the default is Bochs, but
+@option{--qemu} selects QEMU. You can run the simulator
+with a debugger (@pxref{GDB}). You can set the amount of memory to give
the VM. Finally, you can select how you want VM output to be displayed:
use @option{-v} to turn off the VGA display, @option{-t} to use your
terminal window as the VGA display instead of opening a new window
-(Bochs only), or @option{-s} to suppress the serial output to
-@code{stdout}.
+(Bochs only), or @option{-s} to suppress serial input from @code{stdin}
+and output to @code{stdout}.
The Pintos kernel has commands and options other than @command{run}.
These are not very interesting for now, but you can see a list of them
@node Debugging versus Testing
@subsection Debugging versus Testing
-When you're debugging code, it's useful to be able to be able to run a
+When you're debugging code, it's useful to be able to run a
program twice and have it do exactly the same thing. On second and
later runs, you can make new observations without having to discard or
verify your old observations. This property is called
-``reproducibility.'' The simulator we use by default, Bochs, can be set
-up for
+``reproducibility.'' One of the simulators that Pintos supports, Bochs,
+can be set up for
reproducibility, and that's the way that @command{pintos} invokes it
by default.
second of real time. Simulation in real-time mode is not reproducible,
and options @option{-j} and @option{-r} are mutually exclusive.
-On the Linux machines only, the qemu simulator is available as an
+The QEMU simulator is available as an
alternative to Bochs (use @option{--qemu} when invoking
-@command{pintos}). The qemu simulator is much faster than Bochs, but it
+@command{pintos}). The QEMU simulator is much faster than Bochs, but it
only supports real-time simulation and does not have a reproducible
mode.
of the test results.
For project 1, the tests will probably run faster in Bochs. For the
-rest of the projects, they will probably run faster in qemu.
+rest of the projects, they will run much faster in QEMU.
+@command{make check} will select the faster simulator by default, but
+you can override its choice by specifying @option{SIMULATOR=--bochs} or
+@option{SIMULATOR=--qemu} on the @command{make} command line.
You can also run individual tests one at a time. A given test @var{t}
writes its output to @file{@var{t}.output}, then a script scores the
specifying @option{VERBOSE=1} on the @command{make} command line, as in
@code{make check VERBOSE=1}. You can also provide arbitrary options to the
@command{pintos} run by the tests with @option{PINTOSOPTS='@dots{}'},
-e.g.@: @code{make check PINTOSOPTS='--qemu'} to run the tests under
-qemu.
+e.g.@: @code{make check PINTOSOPTS='-j 1'} to select a jitter value of 1
+(@pxref{Debugging versus Testing}).
All of the tests and related files are in @file{pintos/src/tests}.
Before we test your submission, we will replace the contents of that
code that you submit. We will read your entire design document and much
of your source code.
+Don't forget that design quality, including the design document, is 50%
+of your project grade. It
+is better to spend one or two hours writing a good design document than
+it is to spend that time getting the last 5% of the points for tests and
+then trying to rush through writing the design document in the last 15
+minutes.
+
+@menu
+* Design Document::
+* Source Code::
+@end menu
+
+@node Design Document
+@subsubsection Design Document
+
We provide a design document template for each project. For each
significant part of a project, the template asks questions in four
-areas: data structures, algorithms, synchronization, and rationale. An
-incomplete design document or one that strays from the template without
-good reason may be penalized. Incorrect capitalization, punctuation,
-spelling, or grammar can also cost points. @xref{Project
-Documentation}, for a sample design document for a fictitious project.
+areas:
+
+@table @strong
+@item Data Structures
+
+The instructions for this section are always the same:
+
+@quotation
+Copy here the declaration of each new or changed @code{struct} or
+@code{struct} member, global or static variable, @code{typedef}, or
+enumeration. Identify the purpose of each in 25 words or less.
+@end quotation
+
+The first part is mechanical. Just copy new or modified declarations
+into the design document, to highlight for us the actual changes to data
+structures. Each declaration should include the comment that should
+accompany it in the source code (see below).
+
+We also ask for a very brief description of the purpose of each new or
+changed data structure. The limit of 25 words or less is a guideline
+intended to save your time and avoid duplication with later areas.
+
+@item Algorithms
+
+This is where you tell us how your code works, through questions that
+probe your understanding of your code. We might not be able to easily
+figure it out from the code, because many creative solutions exist for
+most OS problems. Help us out a little.
-Design quality will also be judged based on your source code. We will
+Your answers should be at a level below the high level description of
+requirements given in the assignment. We have read the assignment too,
+so it is unnecessary to repeat or rephrase what is stated there. On the
+other hand, your answers should be at a level above the low level of the
+code itself. Don't give a line-by-line run-down of what your code does.
+Instead, use your answers to explain how your code works to implement
+the requirements.
+
+@item Synchronization
+
+An operating system kernel is a complex, multithreaded program, in which
+synchronizing multiple threads can be difficult. This section asks
+about how you chose to synchronize this particular type of activity.
+
+@item Rationale
+
+Whereas the other sections primarily ask ``what'' and ``how,'' the
+rationale section concentrates on ``why.'' This is where we ask you to
+justify some design decisions, by explaining why the choices you made
+are better than alternatives. You may be able to state these in terms
+of time and space complexity, which can be made as rough or informal
+arguments (formal language or proofs are unnecessary).
+@end table
+
+An incomplete, evasive, or non-responsive design document or one that
+strays from the template without good reason may be penalized.
+Incorrect capitalization, punctuation, spelling, or grammar can also
+cost points. @xref{Project Documentation}, for a sample design document
+for a fictitious project.
+
+@node Source Code
+@subsubsection Source Code
+
+Your design will also be judged by looking at your source code. We will
typically look at the differences between the original Pintos source
tree and your submission, based on the output of a command like
@code{diff -urpb pintos.orig pintos.submitted}. We will try to match up your
discrepancies between the description and the actual code will be
penalized, as will be any bugs we find by spot checks.
-The most important aspects of design quality are those that specifically
+The most important aspects of source code design are those that specifically
relate to the operating system issues at stake in the project. For
example, the organization of an inode is an important part of file
system design, so in the file system project a poorly designed inode
Pintos is written in a consistent style. Make your additions and
modifications in existing Pintos source files blend in, not stick out.
In new source files, adopt the existing Pintos style by preference, but
-make the self-consistent at the very least. Use horizontal and vertical
-white space to make code readable. Add a comment to every structure,
-structure member, global or static variable, and function definition.
-Update existing comments as you modify code. Don't comment out or use
-the preprocessor to ignore blocks of code. Use assertions to document
-key invariants. Decompose code into functions for clarity. Code that
-is difficult to understand because it violates these or other ``common
-sense'' software engineering practices will be penalized.
+make your code self-consistent at the very least. There should not be a
+patchwork of different styles that makes it obvious that three different
+people wrote the code. Use horizontal and vertical white space to make
+code readable. Add a brief comment on every structure, structure
+member, global or static variable, typedef, enumeration, and function
+definition. Update
+existing comments as you modify code. Don't comment out or use the
+preprocessor to ignore blocks of code (instead, remove it entirely).
+Use assertions to document key invariants. Decompose code into
+functions for clarity. Code that is difficult to understand because it
+violates these or other ``common sense'' software engineering practices
+will be penalized.
In the end, remember your audience. Code is written primarily to be
read by humans. It has to be acceptable to the compiler too, but the
compiler doesn't care about how it looks or how well it is written.
-@node License
-@section License
+@node Legal and Ethical Issues
+@section Legal and Ethical Issues
Pintos is distributed under a liberal license that allows free use,
modification, and distribution. Students and others who work on Pintos
own the code that they write and may use it for any purpose.
-
-In the context of Stanford's CS 140 course, please respect the spirit
-and the letter of the honor code by refraining from reading any homework
-solutions available online or elsewhere. Reading the source code for
-other operating system kernels, such as Linux or FreeBSD, is allowed,
-but do not copy code from them literally. Please cite the code that
-inspired your own in your design documentation.
-
Pintos comes with NO WARRANTY, not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.
+@xref{License}, for details of the license and lack of warranty.
-The @file{LICENSE} file at the top level of the Pintos source
-distribution has full details of the license and lack of warranty.
+@localhonorcodepolicy{}
@node Acknowledgements
@section Acknowledgements
-Pintos and this documentation were written by Ben Pfaff
-@email{blp@@cs.stanford.edu}.
+The Pintos core and this documentation were originally written by Ben
+Pfaff @email{blp@@cs.stanford.edu}.
+
+Additional features were contributed by Anthony Romano
+@email{chz@@vt.edu}.
+
+The GDB macros supplied with Pintos were written by Godmar Back
+@email{gback@@cs.vt.edu}, and their documentation is adapted from his
+work.
The original structure and form of Pintos was inspired by the Nachos
instructional operating system from the University of California,
-Berkeley. A few of the source files were originally more-or-less
-literal translations of the Nachos C++ code into C. These files bear
-the original UCB license notice.
+Berkeley (@bibref{Christopher}).
A few of the Pintos source files are derived from code used in the
Massachusetts Institute of Technology's 6.828 advanced operating systems
course. These files bear the original MIT license notice.
The Pintos projects and documentation originated with those designed for
-Nachos by current and former CS140 teaching assistants at Stanford
+Nachos by current and former CS 140 teaching assistants at Stanford
University, including at least Yu Ping, Greg Hutchins, Kelly Shaw, Paul
-Twohey, Sameer Qureshi, and John Rector. If you're not on this list but
-should be, please let me know.
+Twohey, Sameer Qureshi, and John Rector.
-Example code for condition variables (@pxref{Condition Variables}) is
+Example code for monitors (@pxref{Monitors}) is
from classroom slides originally by Dawson Engler and updated by Mendel
-Roseblum.
+Rosenblum.
+
+@localcredits{}
@node Trivia
@section Trivia
Pintos originated as a replacement for Nachos with a similar design.
Since then Pintos has greatly diverged from the Nachos design. Pintos
differs from Nachos in two important ways. First, Pintos runs on real
-or simulated 80@var{x}86 hardware, whereas Nachos runs as a process on a
-host operating system. Second, like most real-world operating systems,
-Pintos is written in C, whereas Nachos is written in C++.
+or simulated 80@var{x}86 hardware, but Nachos runs as a process on a
+host operating system. Second, Pintos is written in C like most
+real-world operating systems, but Nachos is written in C++.
Why the name ``Pintos''? First, like nachos, pinto beans are a common
Mexican food. Second, Pintos is small and a ``pint'' is a small amount.
projects / pintos-anon / blobdiff