Introduction
Welcome to Pintos. Pintos is a simple operating system framework for the 80x86 architecture. It supports kernel threads, loading and running user programs, and a file system, but it implements all of these in a very simple way. In the Pintos projects, you and your project team will strengthen its support in all three of these areas. 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 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 80x86 CPU and its peripheral devices accurately enough that unmodified operating systems and software can run under it. In class we will use the Bochs and QEMU simulators. Pintos has also been tested with VMware Player.
These projects are hard. They have 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 feedback. If you have suggestions on how we can reduce the unnecessary overhead of assignments, cutting them down to the important underlying issues, please let us know.
This chapter explains how to get started working with Pintos. You should read the entire chapter before you start work on any of the projects.
Getting Started
Source Tree Overview
Once you've formed a group, you will have a group repository in which you'll work on pintos. But for now you can look at the source code in Pintos in this read-only github repository.
Let's take a look at what's inside. Here's the directory structure
that you should see in pintos/src
:
threads/
- Source code for the base kernel, which you will modify starting in
project 0.
userprog/
- Source code for the user program loader, which you will modify
starting with project 2.
vm/
- An almost empty directory. You wont be implementing virtual memory in cs162. (typically project 3)
filesys/
- Source code for a basic file system. You will use this file system
starting with project 2, but you will not modify it (that would typically be project 4 in some courses).
devices/
- Source code for I/O device interfacing: keyboard, timer, disk, etc.
You will modify the timer implementation in project 0. Otherwise
you should have no need to change this code.
lib/
- An implementation of a subset of the standard C library. The code in
this directory is compiled into both the Pintos kernel and, starting
from project 2, user programs that run under it. In both kernel code
and user programs, headers in this directory can be included using the
#include <...>
notation. You should have little need to modify this code. lib/kernel/
- Parts of the C library that are included only in the Pintos kernel.
This also includes implementations of some data types that you are
free to use in your kernel code: bitmaps, doubly linked lists, and
hash tables. In the kernel, headers in this
directory can be included using the
#include <...>
notation. lib/user/
- Parts of the C library that are included only in Pintos user programs.
In user programs, headers in this directory can be included using the
#include <...>
notation. tests/
- Tests for each project. You can modify this code if it helps you test
your submission, but we will replace it with the originals before we run
the tests.
examples/
- Example user programs for use starting with project 2.
misc/
utils/
- These files may come in handy if you decide to try working with Pintos on your own machine. Otherwise, you can ignore them.
Building Pintos
As the next step, build the source code supplied for
the first project. First, cd
into the threads
directory. Then, issue the make
command. This will create a
build
directory under threads
, populate it with a
Makefile
and a few subdirectories, and then build the kernel
inside. The entire build should take less than 30 seconds.
Following the build, the following are the interesting files in the
build
directory:
Makefile
- A copy of
pintos/src/Makefile.build
. It describes how to build the kernel. See Adding Source Files, for more information. kernel.o
- 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
GDB (see section E.5 GDB) or
backtrace
(see section E.4 Backtraces) on it. kernel.bin
- Memory image of the kernel, that is, the exact bytes loaded into
memory to run the Pintos kernel. This is just
kernel.o
with debug information stripped out, which saves a lot of space, which in turn keeps the kernel from bumping up against a 512 kB size limit imposed by the kernel loader's design. loader.bin
- Memory image for the kernel loader, a small chunk of code written in assembly language that reads the kernel from disk into memory and starts it up. It is exactly 512 bytes long, a size fixed by the PC BIOS.
Subdirectories of build
contain object files (.o
) and
dependency files (.d
), both produced by the compiler. The
dependency files tell make
which source files need to be
recompiled when other source or header files are changed.
Running Pintos
We've supplied a program for conveniently running Pintos in a simulator,
called pintos
. In the simplest case, you can invoke
pintos
as pintos argument...
. Each
argument is passed to the Pintos kernel for it to act on.
Try it out. First cd
into the newly created build
directory. Then issue the command pintos run alarm-multiple
,
which passes the arguments run alarm-multiple
to the Pintos
kernel. In these arguments, run
instructs the kernel to run a
test and alarm-multiple
is the test to run.
This command creates a bochsrc.txt
file, which is needed for
running Bochs, and then invoke Bochs. Bochs opens a new window that
represents the simulated machine's display, and a BIOS message briefly
flashes. Then Pintos boots and runs the alarm-multiple
test
program, which outputs a few screenfuls of text. When it's done, you
can close Bochs by clicking on the "Power" button in the window's top
right corner, or rerun the whole process by clicking on the "Reset"
button just to its left. The other buttons are not very useful for our
purposes.
(If no window appeared at all, then you're probably logged in remotely and X
forwarding is not set up correctly. In this case, you can fix your X
setup, or you can use the -v
option to disable X output:
pintos -v -- run alarm-multiple
.)
The text printed by Pintos inside Bochs probably went by too quickly to
read. However, you've probably noticed by now that the same text was
displayed in the terminal you used to run 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
stdin
and stdout
. You can log serial output to a file by
redirecting at the
command line, e.g. pintos run alarm-multiple > logfile
.
The pintos
program offers several options for configuring the
simulator or the virtual hardware. If you specify any options, they
must precede the commands passed to the Pintos kernel and be separated
from them by --
, so that the whole command looks like
pintos option... -- argument...
. Invoke
pintos
without any arguments to see a list of available options.
Options can select a simulator to use: the default is Bochs, but
--qemu
selects QEMU. You can run the simulator
with a debugger (see section E.5 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 -v
to turn off the VGA display, -t
to use your
terminal window as the VGA display instead of opening a new window
(Bochs only), or -s
to suppress serial input from stdin
and output to stdout
.
The Pintos kernel has commands and options other than run
.
These are not very interesting for now, but you can see a list of them
using -h
, e.g. pintos -h
.
Adding Source Files
To add a .c
file, edit the top-level Makefile.build
. Add the new file to
variable dir_SRC
, where dir
is the directory where you added the
file. For this project, that means you should add it to threads_SRC
or
devices_SRC
. Then run make
. If your new file doesn't get compiled, run
make clean
and then try again.
When you modify the top-level Makefile.build
and re-run make
, the modified
version should be automatically copied to threads/build/Makefile
. The converse is not
true, so any changes will be lost the next time you run make clean
from the
threads
directory. Unless your changes are truly temporary, you should prefer to edit
Makefile.build
.
A new .h
file does not require editing the Makefile
s.
Debugging versus Testing
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." One of the simulators that Pintos supports, Bochs,
can be set up for
reproducibility, and that's the way that pintos
invokes it
by default.
Of course, a simulation can only be reproducible from one run to the next if its input is the same each time. For simulating an entire computer, as we do, this means that every part of the computer must be the same. For example, you must use the same command-line argument, the same disks, the same version of Bochs, and you must not hit any keys on the keyboard (because you could not be sure to hit them at exactly the same point each time) during the runs.
While reproducibility is useful for debugging, it is a problem for testing thread synchronization, an important part of most of the projects. In particular, when Bochs is set up for reproducibility, timer interrupts will come at perfectly reproducible points, and therefore so will thread switches. That means that running the same test several times doesn't give you any greater confidence in your code's correctness than does running it only once.
So, to make your code easier to test, we've added a feature, called
"jitter," to Bochs, that makes timer interrupts come at random
intervals, but in a perfectly predictable way. In particular, if you
invoke pintos
with the option -j seed
, timer
interrupts will come at irregularly spaced intervals. Within a single
seed value, execution will still be reproducible, but timer
behavior will change as seed is varied. Thus, for the highest
degree of confidence you should test your code with many seed values.
On the other hand, when Bochs runs in reproducible mode, timings are not
realistic, meaning that a "one-second" delay may be much shorter or
even much longer than one second. You can invoke pintos
with
a different option, -r
, to set up Bochs for realistic
timings, in which a one-second delay should take approximately one
second of real time. Simulation in real-time mode is not reproducible,
and options -j
and -r
are mutually exclusive.
The QEMU simulator is available as an
alternative to Bochs (use --qemu
when invoking
pintos
). The QEMU simulator is much faster than Bochs, but it
only supports real-time simulation and does not have a reproducible
mode.
Testing
Each project has several tests, each of which has a name beginning with tests
.
To completely test your submission, invoke make check
from the
project build
directory. This will build and run each test and
print a "pass" or "fail" message for each one. When a test fails,
make check
also prints some details of the reason for failure.
After running all the tests, make check
also prints a summary
of the test results.
For project 1, the tests will probably run faster in Bochs. For project 2,
they will run much faster in QEMU.
make check
will select the faster simulator by default, but
you can override its choice by specifying SIMULATOR=--bochs
or
SIMULATOR=--qemu
on the make
command line.
You can also run individual tests one at a time. A given test t
writes its output to t.output
, then a script scores the
output as "pass" or "fail" and writes the verdict to
t.result
. To run and grade a single test, make
the .result
file explicitly from the build
directory, e.g.
make tests/threads/alarm-multiple.result
. If make
says
that the test result is up-to-date, but you want to re-run it anyway,
either run make clean
or delete the .output
file by hand.
By default, each test provides feedback only at completion, not during
its run. If you prefer, you can observe the progress of each test by
specifying VERBOSE=1
on the make
command line, as in
make check VERBOSE=1
. You can also provide arbitrary options to the
pintos
run by the tests with PINTOSOPTS='...'
,
e.g. make check PINTOSOPTS='-j 1'
to select a jitter value of 1
(see section 1.1.4 Debugging versus Testing).
All of the tests and related files are in pintos/src/tests
.
Before we test your submission, we will replace the contents of that
directory by a pristine, unmodified copy, to ensure that the correct
tests are used. Thus, you can modify some of the tests if that helps in
debugging, but we will run the originals.
All software has bugs, so some of our tests may be flawed. If you think a test failure is a bug in the test, not a bug in your code, please point it out. We will look at it and fix it if necessary.
Please don't try to take advantage of our generosity in giving out our test suite. Your code has to work properly in the general case, not just for the test cases we supply. For example, it would be unacceptable to explicitly base the kernel's behavior on the name of the running test case. Such attempts to side-step the test cases will receive no credit. If you think your solution may be in a gray area here, please ask us about it.
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. Pintos comes with NO WARRANTY, not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See section License, for details of the license and lack of warranty.
In the context of Berkeley's CS 162 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.
Acknowledgements
The Pintos core and this documentation were originally written by Ben Pfaff blp@cs.stanford.edu.
Additional features were contributed by Anthony Romano chz@vt.edu.
The GDB macros supplied with Pintos were written by Godmar Back 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 ([ Christopher]).
The Pintos projects and documentation originated with those designed for 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.
Example code for monitors (see section A.3.4 Monitors) is from classroom slides originally by Dawson Engler and updated by Mendel Rosenblum.
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 80x86 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. Third, like drivers of the eponymous car, students are likely to have trouble with blow-ups.