[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 CSE 451 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. CSE 451 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 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.
For CSE 451 we will provide you with a Linux virtual machine image for development and testing of Pintos. We will test your code in this same VM environment. Our instructions will assume this environment.
You can run this VM image in any VM player. You may choose to run your image on your own computer or on the instructional machines. forkbomb.cs.washington.edu is reserved for CSE 451.
It is perfectly possible to work on Pintos on your own machine, though we cannot reasonably support you in doing so. Nevertheless, we provide instructions to help if this is the path you choose (see section F. Installing Pintos).
Obtain the source for Pintos using Git. Git should come pre-installed in your VM. Use the command:
git clone https://github.com/willscott/pintos.git ~/pintos |
This will copy the latest version of the project into a directory called pintos
in the home directory of your VM.
You'll need to do a couple more things in your VM before you're able to work on Pintos.
Pintos supports two different simulators: Bochs and QEMU.
It is unfortunately necessary to build Bochs with a few custom flags in order to support the debugging features you'll want to use throughout this project. Fortunately, we have a script that will build it for you. Issue the following commands:
cd ~/pintos/src/misc sh install-bochs.sh |
This will invoke a series of actions to build and install Bochs into ~/pintos/build
.
You will only be able to install QEMU within your own VM. It should already be installed on the instructional machines and on forkbomb.
To install QEMU, open a shell in your VM and issue the command:
sudo yum install qemu |
Yum (the package manager of your Fedora VM) may prompt you about whether what it is about to do is okay; you should answer "y". The package manager will download and install QEMU. No more setup should be needed for QEMU to work with Pintos.
You'll need to add a number of Pintos utilities to your path, along with the custom version of bochs you installed. In order to do so, run the following commands:
cd ~/pintos/src/misc sh setup-path.sh |
This will cause your path to be set every subsequent time you start a shell.
Open a new shell (or run source ~/.bashrc
). pintos
should now print usage instructions. Likewise,
the bochs
header should note that it was build from an SVN snapshot.
Here we'll show you how to compile and run Pintos. Pintos comes with quite a bit of basic functionality included and is capable of being compiled straight out of the box. You'll add a lot to it in the coming weeks of the quarter, but for now let's just compile the base code and make sure we can get it to run.
Change directory to the src/threads
directory and run make
, like so:
cd ~/pintos/src/threads make |
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. The contents of the build
directory are described below.
One of the programs you included in your path earlier is an executable
called pintos
. This program conveniently starts Pintos
in a simulator.
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 -v -- run alarm-multiple |
This runs the test-case alarm-multiple
. Try alarm-single
. These are tests against which your code will be tested in grading, and they're your first line of testing to make sure that your code does what you think it does.
Everything after --
in the line above (run alarm-multiple
in this case) is an argument passed to the Pintos kernel that tells it what to do. Everything before is an argument to the Pintos utility, telling it how to configure the simulator and other options. -v turns off VGA-simulation.
The command pintos
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.
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. In the example above, you used the option -v
, which turns off VGA output. Try removing it and seeing the difference.
We have found in testing that VGA output is resource intensive and can be crashy and slow. Your mileage may vary, so try the various output options described below.
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 D.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
.
Here's the directory structure that you should see in pintos/src
:
threads/
userprog/
vm/
filesys/
devices/
lib/
#include <...>
notation. You should have little need to
modify this code.
lib/kernel/
#include <...>
notation.
lib/user/
#include <...>
notation.
tests/
examples/
misc/
utils/
Following the build, the following are the interesting files in the
build
directory:
Makefile
pintos/src/Makefile.build. It describes how to build the kernel. See Adding Source Files, for more information.
kernel.o
backtrace
(see section D.4 Backtraces) on it.
kernel.bin
kernel.owith 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
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.
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, is executed by pintos
to provide reproducibility.
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.
The key lesson here is that running the same thing repeatedly with the same inputs doesn't guarantee that it actually works. Beware of bugs that are hidden by the reproducible timings of the simulator.
We will grade your assignments based on test results and design quality, each of which comprises 50% of your grade.
Your test result grade will be based on our tests. 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 the
rest of the projects, 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.9 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.
We will judge your design based on the design document and the source 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.
We provide a design document template for each project. For each significant part of a project, the template asks questions in four areas:
The instructions for this section are always the same:
Copy here the declaration of each new or changedstruct
orstruct
member, global or static variable,typedef
, or enumeration. Identify the purpose of each in 25 words or less.
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.
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.
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.
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.
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).
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. See section C. Project Documentation, for a sample design document for a fictitious project.
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
diff -urpb pintos.orig pintos.submitted
. We will try to match up your
description of the design with the code submitted. Important
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 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 would lose points. Other issues are much less important. For example, multiple Pintos design problems call for a "priority queue," that is, a dynamic collection from which the minimum (or maximum) item can quickly be extracted. Fast priority queues can be implemented many ways, but we do not expect you to build a fancy data structure even if it might improve performance. Instead, you are welcome to use a linked list (and Pintos even provides one with convenient functions for sorting and finding minimums and maximums).
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 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.
Submissions will be made through the Catalyst dropbox for the course. You will be working in a group. All group members should submit your groups design document for the assignment. This allows the TAs to provide feedback / grades to all group members. One members should also upload your code submission. The code submission should be created as follows:
cd ~/pintos cd src && make clean tar --exclude=src/misc/bochs -cvzf submission.tgz src/ |
These commands can also be run via the script src/misc/package.sh
.
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 CSE 451, please 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 code or other sources (stackoverflow, forums, etc.) that inspired your own solutions.
See the webpage at http://www.cs.washington.edu/451 for more details on academic honesty.
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.
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.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |