Due: Thursday at 9:00pm, April 7, 2016
The project is to be done in groups of 2-3. Everyone in the group should be able to answer the questions in this assignment. If you have not formed a group yet, please get started on the assignment anyway, and then compare answers and resolve any questions you may still have.
The purpose of this assignment is to introduce you to the code you will be using throughout the rest of the course. We will do portions of this assignment in section. Even if you found answers to some of these questions during section, include them in the solution you turn in.
By the time you complete this assignment and the related in-class work, you should be able to:
You must turn in the answers to the code-reading questions via Catalyst.
git clone git@gitlab.cs.washington.edu:syslab/16sp_cse451_os161.git mv 16sp_cse451_os161 os161
This creates a directory named os161 containing the source code for the operating system and various utilities.
The operating system is written for a cache-coherent MIPS computer named System/161. For this, you will need to use a cross-compiler: a compiler for generating MIPS instructions, along with various other related tools such as a cross-gdb.
You will need to put the following directory in your UNIX path:
/usr/local/os161/tools/binIn this directory you will find all the necessary tools, such as mips-harvard-os161-gdb and mips-harvard-os161-gcc. You will probably want to set up an alias in your shell so you can use os161gdb instead of the full name.
To use the tools within a VM, follow the following steps (from support@cs):
"The Home VM looks at our local courseware repository, so the packages can also be installed there. For someone who has just downloaded the Home VM, they should first apply all the updates since the home VM was created with "sudo dnf -y update". After that, they can install the toolchain by doing:
sudo dnf -y install bmake os161-environment binutils+os161 gcc+os161 gdb+os161 sys161After installing, they should log out of the VM and in again to get the toolchain path added to their environment."
Typical practice when developing a new OS is to run it on a machine simulator. The simulator, sys161, is in the same directory as the cross-compile binaries, along with a few other versions like trace161 and stats161 that may be useful later.
You will want a repository for your group to store its code, to share solutions with the TA's, and most importantly, to allow you to pull/merge any changes we make later on.
Go into UW CSE's gitlab and create a new project (typically, one per group). Then follow the instructions under "Existing folder or Git repository" for pushing a clean version of the os161 code into that project. You will also need to enable write access for your partners and read access for the TA's.
Next, tag your repository to indicate that you are beginning assignment 0. In your git repository, issue the following command:
git tag asst0-start
Then push the tag to your shared repository.
git push origin master --tags
OS/161 is a simplified skeleton of a modern operating system. It comes with a configurable build system, code for some useful user-level utilities that can be run from within OS/161, and of course code for the operating system itself. To complete the assignments of this course, you will need to get your hands deep in the guts of the OS/161 codebase, and the sooner you become familiar with it, the better. To that end, you should look through the files and begin to internalize how the code is structured, what goes where, and how things work. This applies both to the build system and the codebase itself.
To guide you in this process, please write up and submit to the catalyst course dropbox a file with the answers to the questions below. Make sure to include the names of all project partners.
The questions are designed to encourage code exploration (we tried to avoid questions you could answer simply using grep). The goal is to help you understand key parts of the system. That said, you are not yet expected to understand everything you see (that's what the rest of the course is for!). But you should get the "gist," and your answers should reflect that. Please give function names and full pathnames in the source tree where appropriate. You don't need to explain what every last line of a function does, but your answers should be conceptually complete. Note that some questions may require longer answers than others.
Note: in these questions, and throughout the course of the semester, we will refer to the terms "trap", "interrupt", "exception", and "system call". Following the textbook, they mean the following:
Let's begin with some discussion questions:
Below is a brief overview of the organization of the source tree, and a description of what goes where.
configure -- top-level configuration script; configures the OS/161 distribution, including all the provided utilities, but does not configure the operating system kernel.
Question 4: Name two things that configure configures? What might invalidate that configuration and make you need/want to run configure again?
Makefile -- top-level makefile; builds the OS/161 distribution, including all the provided utilities, but does not build the operating system kernel.
common/ -- code used both by the kernel and user-level programs, mostly standard C library functions.
kern/ -- the kernel source code.
kern/Makefile -- Once again, there is a Makefile. This Makefile installs header files but does not build anything.
kern/arch/ -- This is where architecture-specific code goes. By architecture-specific, we mean the code that differs depending on the hardware platform on which you're running. There are two directories here: mips which contains code specific to the MIPS processor and sys161 which contains code specific to the System/161 simulator.
kern/arch/mips/conf/conf.arch -- This tells the kernel config script where to find the machine-specific, low-level functions it needs (throughout kern/arch/mips/*).
kern/arch/mips/include/ -- This folder and its subdirectories include files for the machine-specific constants and functions.
Discuss Me! Question 5: What are some of the details which would make a function "machine dependent"? Why might it be important to maintain this separation, instead of just putting all of the code in one function?
kern/arch/mips/* -- The other directories contain source files for the machine-dependent code that the kernel needs to run. A lot of this code is in assembler and will seem very low level, but understanding how it all fits together will help you immensely on Assignment 2.
Question 6: Where is the first line of code for constructing a trapframe? How large is a trapframe? Why?kern/arch/sys161/conf/conf.arch -- Similar to mips/conf/conf.arch.
kern/arch/sys161/include -- These files are include files for the System161-specific hardware, constants, and functions. machine-specific constants and functions.
kern/compile -- This is where you build kernels. See below.
Question 7: For each scenario, state which of the following actions (a, b, c, d) you must take to compile your kernel (a scenario might require more than one action or none at all).
Scenario 1. You just finished assignment 1 and are ready to start assignment 2.
Scenario 2. You added #include <cpu.h> at the top of kern/thread/synch.c.
Scenario 3. You added a new file foo.c with a corresponding foo.h.
Scenario 4. You added code in kern/thread/synch.c to implement locks and condition variables.
Scenario 5. You edited sys161.conf to change the size of physical memory for System/161.
kern/dev -- This is where all the low level device management code is stored. Unless you are really interested, you can safely ignore most of this directory.
kern/fs -- This is where the actual file system implementations go. The subdirectory sfs contains a simple default file system. You would have augmented this file system as part of Assignment 4, but we're on quarters, so you'll need to do that one over the summer if you are interested.
kern/include -- These are the include files that the kernel needs. The kern subdirectory contains include files that are visible not only to the operating system itself, but also to user-level programs. (Think about why it's named "kern" and where the files end up when installed.)
kern/lib -- These are library routines used throughout the kernel, e.g., arrays, kernel printf, etc. Note: You can use these data structures as you implement your assignments. We strongly encourage you to look around and see what we've provided for you.
kern/main -- This is where the kernel is initialized and where the kernel main function is implemented.
Question 8: When you booted your kernel, you found that there were several commands that you could issue. Explain exactly where and what you would have to do to add a command that printed out, "Hello world!"
kern/proc -- This is where process support lives. You will write most of the code that goes here during Assignment 2.
kern/syscall -- This is where you will add code to create and manage user level processes. As it stands now, OS/161 runs only kernel threads; there is no support for user level code. In Assignment 2, you'll implement this support.
kern/thread -- Threads are the fundamental abstraction on which the kernel is built (do not forget to look back at header files!)
kern/vfs -- The vfs is the "virtual file system." It is an abstraction for a file system and its existence in the kernel allows you to implement multiple file systems, while sharing as much code as possible. The VFS layer is the file-system independent layer. You will want to go look at vfs.h and vnode.h before looking at this directory.
kern/vm -- This directory is fairly vacant. In Assignment 3, you'll implement virtual memory and most of your code will go in here.
/man/ -- the OS/161 manual ("man pages") appear here. The man pages document (or specify) every program, every function in the C library, and every system call. You will use the system call man pages for reference in the course of assignment 2. The man pages are HTML and can be read with any browser.
/mk/ -- fragments of makesfiles used to build the system.
/userland/ -- user-level libraries and program code
/userland/bin/ -- all the utilities that are typically found in /bin, e.g., cat, cp, ls, etc. The things in bin are considered "fundamental" utilities that the system needs to run.
Question 9: Why do we need to include these in your OS/161 distribution? Why can't you just use the standard utilities that are present on the machine on which you're working?
/userland/include/ -- these are the include files that you would typically find in /usr/include (in our case, a subset of them). These are user level include files; not kernel include files.
/userland/lib/ -- library code lives here. We have only two libraries: libc, the C standard library, and hostcompat, which is for recompiling OS/161 programs for the host UNIX system. There is also a crt0 directory, which contains the startup code for user programs.
Question 10: When a user program returns from main, what is done with the value it returns?
/userland/sbin/ -- this is the source code for the utilities typically found in /sbin on a typical UNIX installation. In our case, there are some utilities that let you halt the machine, power it off and reboot it, among other things.
/userland/testbin/ -- these are pieces of test code.
Discuss Me! Question 11: Suppose you wanted to add a new system call. List all the places that you would need to modify/add code. Then review your answers to question 7 and state which additional actions you would need to take in order to test the new system call.
Discuss Me! Question 12: Refer to the document Using GDB and run gdb on your kernel. Experiment a bit and follow the execution from the start.S file through the main menu kmain and then to the code that executes some of the commands. Explain the control flow from start.S through the menu and on to other parts of the kernel. There is no need to trace functions called by functions called by kmain, but you should look at those functions to understand what the first level function does.
Congratulations! You're done with assignment 0!