Introduction

Welcome to Pintos. Pintos is a simple operating system framework for the 80×86 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.

We will run Pintos projects in a system simulator, that is, a program that simulates an 80×86 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. Pintos 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.

1.1 Getting Started

For widely used OSes these days (Windows, Mac, Linux), we provide ways to construct a development environment. We need a UNIX-based OS to run simulators and building systems that Pintos requires.

1.1.1 Preparing environments

1.1.1.1 Installing on Windows (Virtual Machine)

One way to run a UNIX system on Windows is to use virtual machines. Popular VM programs are VMWare and VirtualBox.

We need an Ubuntu installation image to install. Download ubuntu-18.04.6-desktop-amd64.iso from https://releases.ubuntu.com/18.04.6/?_ga=2.173865891.1436103949.1646090779-879543907.1646090779.

Create a new Linux virtual machine on the program and install the image. Now you will see it booting successfully.

1.1.1.2 Installing on Windows (WSL)

Windows Subsystem Linux (WSL) is an Linux-compatible system that runs on Windows 10 2004 or higher and Windows 11.

To install, open powershell or Windows Terminal with administrator privilige and run wsl --install.

Details are in https://docs.microsoft.com/en-us/windows/wsl/install.

1.1.1.3 Installing on Linux

Including the above methods that install an Linux OS on Windows, a Linux system needs to install QEMU.

Run sudo apt install qemu.

Make a link to Qemu by running sudo ln -s /usr/bin/qemu-system-i386 /usr/bin/qemu.

Install gcc, g++ and library package by sudo apt install libc6-dev g++ gcc.

1.1.1.4 Installing on MacOS

MacOS also needs to install QEMU.

Run sudo apt install qemu.

Make a link to Qemu by running sudo ln -s /usr/bin/qemu-system-i386 /usr/bin/qemu.

Install gcc, g++ and library package by sudo apt install libc6-dev g++ gcc.

1.1.2 Installing Pintos

Download the source code from this Link. Unzip the file with tar xvf pintos.tar.gz

Before you try running, you have to add paths of your pintos in the shell.

Add export PATH="location_to_your_pintos/src/utils:$PATH" to ~/.bashrc file

Run source ~/.bashrc

To test running, do the following:

First, cd to pintos/src/threads/
$ make
$ cd build
$ pintos -qemu -- -q run alarm-multiple

Then you will see the screen like this:

1.1.3 Source Tree Overview

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

userprog/: Source code for the user program loader, which you will modify starting with project

vm/: An almost empty directory. You will implement virtual memory here in project

filesys/: Source code for a basic file system. You will use this file system starting with project 2, but you will not modify it until project

devices/: Source code for I/O device interfacing: keyboard, timer, disk, etc. You will modify the timer implementation in project 1. 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.

1.1.4 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.

Watch the commands executed during the build. On the Linux machines, the ordinary system tools are used.

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.

1.1.5 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 --qemu -- -q 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.

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.

1.1.6 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.

1.2 Grading

We will grade your assignments based on test results. To make Pintos easier, we made some modifications on the project compared to the original Pintos from Stanford. The grading is based on the test result coming from make check. You can run make check from each module (threads, userprog, vm, filesys) and its sub build/ directory.

Original tasks within make check still remain, and occupy 70% of the grade. We will provide lectures to help accomplishing them. In addition to this, we make newly designed tasks that occupy 30% of the grade. These are a deep but not too complicated tasks to test your comprehension on the project. make grade will visualize the score you get from the assignment.

1.3 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 EE415 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.

1.4 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.

1.5 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×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. Third, like drivers of the eponymous car, students are likely to have trouble with blow-ups.