CS170: Operating Systems (undergrad)

Overview

The main tools in this class are an x86 emulator, called QEMU, and a compiler toolchain (including assembler, linker, loader, C compiler, debugger), which will produce code (often a small-scale operating system) that will run on top of QEMU. These tools are included on the platform on which you will do your lab work. You have two choices for this platform:

A virtual devbox that we provide. Instructions
Machines provided by CSIL (csil.cs.ucsb.edu), on which you all have accounts. Instructions

The choice is up to you; there is no right answer. Each option has advantages and disadvantages. The advantage to the first option is that the lab will run completely on your own computer (and does not require Internet access, provided that you have the lab description locally). A disadvantage is that you have to do a bit more setup (which we describe and walk through below). A second disadvantage is that you will be interacting with two layers of virtualization (the host of the devbox, and then QEMU); this could be confusing. (This could also harm performance, but that will not be a concern for most of the labs.) The second option is the other way around: after your account is set up, you have to do very little setup, and there will be only one layer of virtualization. The disadvantage to this option is that you will be interacting with a computer in a lab somewhere, which requires working over ssh (which in turn requires Internet access).

Option 1: The virtual devbox

One way to ensure that we are all using a uniform development environment (short of us all using the same machine) is for us to use identically configured virtual machines. You can think of a virtual machine as a way to run a particular operating system (in our case, an Ubuntu desktop) on top of another operating system (the one that controls your laptop or desktop).

To get our virtual devbox running, you should do the following:

Download and install on your computer (e.g., your desktop or laptop) a virtualization platform:
- VirtualBox (free for Mac, Linux, Windows): Download page This is the recommended option.
- VMware Player (free for Linux and Windows, registration required)
- VMware Fusion
Download to your computer the virtual devbox image that we have set up for you. Note: the file is 1.5 GB, so the initial download may take some time.
Using the virtualization platform (for example, VirtualBox), import the image that you saved. You can leave all of the settings to their default values. This, too, may take some time.
Using the virtualization platform, start up the virtual machine. You should see an Ubuntu desktop come online.
Login to the machine. Username: cs202. Password: labs.
At this point, you have a machine that will act like an Ubuntu desktop, and you'll do your development on this machine.
If you are using VirtualBox, you will probably want to enlarge the default "monitor size" of the virtual machine. For this to work, the scaling feature must be enabled; this may require pressing a command key plus C, depending on your platform.

Notice the potential confusion from this arrangement. VirtualBox is creating a fake machine (with a fake x86 CPU). Ubuntu desktop is running on that fake machine (though neither Ubuntu desktop nor the applications (compiler, editor, browser) running on Ubuntu desktop are aware that they are running on a fake machine). The confusion enters because one of the applications that you are going to run on Ubuntu desktop is QEMU, and what does QEMU do? It creates another fake machine on which one can run an operating system. In our case, this fake machine will run the lab OSes (the mini operating systems and, perhaps, Linux). To recap: our lab OSes will run on the fake machine that QEMU provides, QEMU is running on Ubuntu desktop, Ubuntu desktop is the operating system for the fake machine that VirtualBox provides, and VirtualBox is running on your computer's operating system (known as the "host" operating system).

All of this is to say that there are actually two levels of virtualization in play. The two levels serve different purposes. The purpose of the lower is to create a uniform devbox. The purpose of the upper is to create the illusion of a physical machine so that you can develop, debug, and run the lab code. (This is a good example of how virtualization serves multiple purposes.)

A potentially interesting point is that although the two levels of virtualization serve different purposes, and although they are implemented with different software (VirtualBox and QEMU, respectively), they accomplish their function using similar technology. We discuss this technology in depth in advanced OS classes. In the meantime, welcome to The Matrix....

Option 2: CSIL machines

Remote Access

Even if you are not on campus, you can access CSIL machines remotely using ssh. We describe the steps below. Follow these steps:

Gain access to the CSIL machines through ssh. The Secure Shell (SSH) establishes an authenticated, encrypted session with a designated machine. You probably want to become comfortable with ssh, if you are not already. A basic guide for interacting with ssh is available here. For more in-depth information, check here.

For Linux and OS X users, open a terminal (xterm or via the Terminal program, etc), and type the following:
```
$ ssh -X [username]@csil.cs.ucsb.edu 
```
In this command, [username] is your CSIL username. The parameter "-X" arranges for graphics painted by the programs you run remotely to show up on your local computer. If you are on OS X and the parameter "-X" does not work for you, try installing XQuartz. If remote access does not work even with XQuartz, try restarting your computer. For some people, the flag "-Y" instead of "-X" also works.
For Windows users, there are several ssh clients. A decent one is PuTTY. We will assume that you are going to use this software.
1. Download Xming and install it.
2. Download PuTTY.
3. Open PuTTY and input csil.cs.ucsb.edu as the hostname.
4. Select "Connection" → "SSH" → "X11" on the left panel, and check the "Enable X11 Forwarding" box.
5. Click on "Open". After the terminal prompt, enter your username and password.

For all users, if you have successfully logged in, you will see a prompt similar to

    [trinabh@csil ~]$

You should also see your home directory.

Optional but recommended: set up "ssh keys", which would remove some of the hassle of typing your password every time you ssh to a machine. For this, see the tutorials above.

You are now ready to begin the labs.

Last updated: 2020-10-05 15:43:34 -0700 [validate xhtml]