4Assignment 0, Systems Software, ECE344, Fall 2011

Assignment 0: An Introduction to OS161

Testing date: Week of Sept 19, 2011 in lab.
Objectives
After this assignment, you should:
Understand how System/161 emulates the MIPS hardware environment on
which OS161 runs.
Be familiar with Subversion (SVN) and GDB (the GNU Debugger).
Setup your account to work on OS161
Understand the source code structure of OS161, the software system we
will be using this term.
Know how to build the OS161 kernel from source.
Learn how to modify the OS161 kernel by adding debugging statements and
system calls.
Learn how to submit assignments.
Deliverables
You will be required to do the following for full marks:
Be able to answer all questions about the source code below (in blue).
Submit code that implements the printstring, printint and helloworld system
calls.
Demonstrate that these system calls work with a comprehensive set of tests
for the system calls.
Introduction
In this assignment, we will introduce:
System/161
The machine simulator for which you are building an operating system this
term.
OS161
The operating system you will be designing, extending, and running this
term.
Subversion (SVN)
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
1 of 17 14-07-23 04:33 PM
SVN is a source code revision control system. It manages the source les of
a software package so that multiple programmers may work simultaneously.
Each programmer has a private copy of the source tree and makes
modications independently. SVN attempts to intelligently merge multiple
people's modications, highlighting potential conicts when it fails.
GDB (Gnu Debugger)
GDB allows you to examine what is happening inside a program while it is
running. It lets you execute programs in a controlled manner and view and
set the values of variables. In the case of OS161, it allows you to debug the
operating system you are building instead of the machine simulator on
which that operating system is running.
The rst part of this document briey discusses the code on which you'll be
working and the tools you'll be using. You can nd more detailed information on
SVN and GDB. The following sections provide instructions on what you must do
for this assignment.
What are OS161 and System/161?
The code is divided into two main parts:
OS161: the operating system that you will augment in subsequent
homework assignments.
System/161: the machine simulator that emulates the physical hardware
on which your operating system will run. This course is about writing
operating systems, not designing or simulating hardware. Therefore, you
may not change the machine simulator.
The OS161 distribution contains a barebones operating system source tree,
including some utility programs and libraries. After you build the operating
system you boot, run, and test it on the simulator.
We use a simulator in OS161 because debugging and testing an operating
system on real hardware is extremely diicult. The System/161 machine
simulator has been found to be an excellent platform for rapid development of
operating system code, while still retaining a high degree of realism. Apart from
oating point support and certain issues relating to RAM cache management, it
provides an accurate emulation of a MIPS processor.
By the end of the semester you will have built an OS that can:
Run multiple programs simultaneously
Support several simple UNIX system calls
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
2 of 17 14-07-23 04:33 PM
Provide virtual memory and swap
OS161 assignments are cumulative. You will need to build each assignment on
top of your previous submission. So you will have to make sure that each of your
assignments work correctly!
About SVN
Most programming you have probably done has been in the form of 'one-o'
assignments: you get an assignment, you complete it yourself, you turn it in, you
get a grade, and then you never look at it again.
The commercial software world uses a very dierent paradigm: development
continues on the same code base producing releases at regular intervals. This
kind of development normally requires multiple people working simultaneously
within the same code base, and necessitates a system for tracking and merging
changes. Your will be working in teams of 2 on OS161 and will be developing a
code base that will change over the couse of several assignments. Therefore, it is
imperative that you start becoming comfortable with SVN, an open source
version control system.
SVN is a powerful tool, but for OS161 you only need to know a subset of its
functionality. The SVN handout contains all the information you need to know
and should serve as a reference throughout the term. If you'd like to learn more,
there is comprehensive documentation available here.
About GDB
In some ways debugging a kernel is no dierent from debugging an ordinary
program. On real hardware, however, a kernel crash will crash the whole
machine, necessitating a time-consuming reboot. The use of a machine simulator
such as System/161 provides several debugging benets. First, a kernel crash
will only crash the simulator, which only takes a few keystrokes to restart.
Second, the simulator can sometimes provide useful information about what the
kernel did to cause the crash, information that may or may not be easily
available when running directly on top of real hardware.
To debug OS161 you must use a version of GDB congured to understand OS161
and MIPS. This is called cs161-gdb. This version of GDB has been patched to be
able to communicate with your kernel through System/161.
An important dierence between debugging a regular program and debugging
an OS161 kernel is that you need to make sure that you are debugging the
operating system, not the machine simulator. Type:
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
3 of 17 14-07-23 04:33 PM
% cs161-gdb sys161
and you are debugging the simulator. Not good. The handout Debugging with
GDB provides detailed instructions on how to debug your operating system and a
brief introduction to GDB.
Setting up your account
Login to the ECF machines. The OS161 tools are accessible from
p1-p170.ecf.toronto.edu. You will need to setup your path to access the OS161
tools. Add the following at the end of your ~/.mycshrc le.
set path=( /local/packages/cs161/bin $path)
If you use bash, add the following at the end of your ~/.bashrc le.
export PATH=/local/packages/cs161/bin:$PATH
Then log out and log back in. Run echo $PATH and you should see the new path.
Getting the distribution
First, download the OS161 source into your home directory.
Optional: In addition to OS161, you can also download the distributions for
System/161, the machine simulator, and the OS161 toolchain. If you are
developing on ECF machines, you do not need these additional les, as they are
already installed. If you wish to develop on your home machine at home, you will
need to download, build, and install this package as well. Note that we do not
provide support for installing this package. Also, you must ensure that your
assignment works on the ECF machines.
Make a directory in which you will do all your work. For the purposes of the
remainder of this assignment, we'll assume that it will be called ~/ece344.
% mkdir ~/ece344
% cd ~/ece344
% mv ../os161-1.11.tar.gz .
1.
Unpack the OS161 distribution by typing
% tar xzf os161-1.11.tar.gz
This will create a directory named os161-1.11
2.
Rename your OS161 source tree to just os161, and remove the tarball.
% mv os161-1.11 os161
% rm os161-1.11.tar.gz
3.
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
4 of 17 14-07-23 04:33 PM
Setting up your SVN repository
Each of you has been assigned a group and a group number. The instructor
or lab TAs will provide you this number. Below, we use <GRP_NR> to denote
your group number. Important: make sure you have submitted your
group members here before starting this step.
1.
Your SVN repository is located at svn+ssh://remote.ecf.utoronto.ca/n/svn
/ece344f_<GRP_NR>. In the document below, this repository path is referred to as
$ECE344_SVN. You can set this variable by adding the following to your
~/.mycshrc.
setenv ECE344_SVN svn+ssh://remote.ecf.utoronto.ca/n/svn/ece344f_<GRP_NR>
If you use bash, add the following at the end of your ~/.bashrc le.
export ECE344_SVN=svn+ssh://remote.ecf.utoronto.ca/n/svn/ece344f_<GRP_NR>
2.
Run
% svn ls $ECE344_SVN
and you should see
tags/
trunk/
3.
Change directories into the OS161 distribution that you unpacked in the
previous section and import your source tree.
% cd ~/ece344/
% svn import os161 $ECE344_SVN/trunk/ -m "Initial import of os161"
% svn copy $ECE344_SVN/trunk $ECE344_SVN/tags/asst0-start -m "Tagging initial import."
You can alter the arguments as you like; here's a quick explanation. -m
"Initial import of os161" is the log message that SVN records. (If you don't
specify it on the command line, it will start up a text editor). /trunk is where
SVN will put the les within your repository. $ECE344_SVN/trunk is the SVN URL
you will specify when you check out your system. Run svn ls on this URL and
you will see that the os161 directories have been imported into your SVN
repository. The second svn copy command creates a simple tag of the initial
import of your system that you can later use with svn diff and other
commands. More on that later (or see this tagging explanation).
4.
Now, remove the source tree that you just imported.
% rm -rf os161
Don't worry - now that you have imported the tree in your repository, there
is a copy saved away. In the next step, you'll get a copy of the source tree
that is yours to work on. You can safely remove the original tree.
5.
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
5 of 17 14-07-23 04:33 PM
Now, checkout a source tree in which you will work.
% svn co $ECE344_SVN/trunk os161
The svn co command creates a working copy of your tree that you can
safely modify in ~/ece344/os161.
6.
Code reading
One of the challenges of OS161 is that you are going to be working with a large
body of code that was written by someone else. When doing so, it is important
that you grasp the overall organization of the entire code base, understand
where dierent pieces of functionality are implemented, and learn how to
augment it in a natural and correct fashion. As you and your partner develop
code, although you needn't understand every detail of your partner's
implementation, you still need to understand its overall structure, how it ts into
the greater whole, and how it works.
In order to become familiar with a code base, there is no substitute for actually
sitting down and reading the code. Admittedly, most code makes poor bedtime
reading (except perhaps as a soporic), but it is essential that you read the code.
It is all right if you don't understand most of the assembly code in the codebase;
it is not important for this class that you know assembly.
You should use the code reading questions included below to help guide you
through reviewing the existing code. While you needn't review every line of code
in the system in order to answer all the questions, we strongly recommend that
you look over at least every le in the kernel.
The key part of this exercise is understanding the base system. Your goal is to
understand how it all ts together so that you can make intelligent design
decisions when you approach future assignments. This may seem tedious, but if
you understand how the system ts together now, you will have much less
diiculty completing future assignments. Also, it may not be apparent yet, but
you have much more time to do so now than you will at any other point in the
term.
The le system, I/O, and network sections may seem confusing since we have not
discussed how these components work. However, it is still useful to review the
code now and get a high-level idea of what is happening in each subsystem. If
you do not understand the low-level details now, that is OK.
These questions are not meant to be tricky -- most of the answers can be found
in comments in the OS161 source, though you may have to look elsewhere (such
as Tannenbaum) for some background information. Make sure that you can
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
6 of 17 14-07-23 04:33 PM
answer these questions during evaluation.
Using Cscope
One very useful tool for navigating source code is cscope. To use cscope, go to
the top level source directory and type "cscope -k -R". Cscope will then
recursively scan the source directory and build a database of functions and
variables. The cscope interface is fairly self explanatory. You can search the
code for functions and variables, and move between the search results and
operations using the tab key. For more information, consult the cscope I3.
Top Level Directory
The top level directory of many software packages is called src or source. In UNIX,
if the operating system source is installed, it is typically found in /usr/src. The top
of the OS/161 source tree is also called src. In this directory, you will nd the
following les:
Makefile: top-level makele; builds the OS/161 distribution, including all
the provided utilities, but does not build the operating system kernel.
configure: this is an autoconf-like script. It sets up things like `How to
run the compiler.' You needn't understand this le, although we'll ask
you to specify certain pathnames and options when you build your own
tree.
defs.mk: this le is generated when you run ./configure. You needn't do
anything to this le.
defs.mk.sample: this is a sample defs.mk le. Ideally, you won't be needing
it either, but if congure fails, use the comments in this le to x
defs.mk.
and the following directories:
bin: this is where the source code lives for 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.
include: these are the include les that you would typically nd in
/usr/include (in our case, a subset of them). These are user level
include les; not kernel include les.
kern: here is where the kernel source code lives.
lib: library code lives here. We have only two libraries: libc, the C
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
7 of 17 14-07-23 04:33 PM
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.
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: this directory contains pieces of makele that are used for building
the system. You don't need to worry about these, although in the long
run we do recommend that anyone working on large software systems
learn to use make eectively.
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 o and reboot it, among other things.
testbin: these are pieces of test code.
You needn't understand every line in every excutable in bin and sbin, but it is
worth the time to peruse a couple to see how they work. Eventually, you will
want to modify these and/or write your own utilities and these are good models.
Similarly, you need not read and understand everything in lib and include, but
you should know enough about what's there to be able to get around the source
tree easily. The rest of this code walk-through is going to concern itself with the
kern subtree.
The Kern Subdirectory
Once again, there is a Makele. This Makele installs header les but does not
build anything. In addition, we have more subdirectories for each component of
the kernel as well as some utility directories. We will ask you questions
(highlighted in blue) during the lab so be sure you can nd the answers
to them!
kern/arch
This is where architecture-specic code goes. By architecture-specic,
we mean the code that diers depending on the hardware platform on
which you're running. For our purposes, you need only concern
yourself with the mips subdirectory.
kern/arch/mips/conf
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
8 of 17 14-07-23 04:33 PM
conf.arch: This tells the kernel cong script where to nd the machine-
specic, low-level functions it needs (see kern/arch/mips/mips).
Makefile.mips: Kernel Makele; this is copied when you "cong a kernel".
kern/arch/mips/include
These les are include les for the machine-specic constants and
functions.
Which register number is used for the stack pointer (sp) in
OS/161?
What bus/busses does OS/161 support?
What is the dierence between splhigh and spl0?
Why do we use typedefs like u_int32_t instead of simply saying
"int"?
kern/arch/mips/mips
These are the source les containing the machine-dependent code that
the kernel needs to run. Most of this code is quite low-level.
What does splx return?
What is the highest interrupt level?
kern/asst1
This is the directory that contains the framework code that you will
need to complete assignment 1. You can safely ignore it for now.
kern/compile
This is where you build kernels. In the compile directory, you will nd
one subdirectory for each kernel you want to build. In a real
installation, these will often correspond to things like a debug build, a
proling build, etc. In our world, each build directory will correspond
to a programming assignment, e.g., ASST1, ASST2, etc. These
directories are created when you congure a kernel (described in the
next section). This directory and build organization is typical of UNIX
installations and is not universal across all operating systems.
kern/conf
cong is the script that takes a cong le, like ASST0, and creates the
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
9 of 17 14-07-23 04:33 PM
corresponding build directory. See how it is used in the section on
Building a Kernel
kern/dev
This is where all the low level device management code is stored.
Unless you pick a particularly low level nal project, you can safely
ignore most of this directory.
kern/include
These are the include les that the kernel needs. The kern
subdirectory contains include les 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 les end up when installed.)
How frequently are hardclock interrupts generated?
What functions comprise the standard interface to a VFS
device?
How many characters are allowed in a volume name?
How many direct blocks does an SFS le have?
What is the standard interface to a le system (i.e., what
functions must you implement to implement a new le system)?
What function puts a thread to sleep?
How large are OS/161 pids?
What operations can you do on a vnode?
What is the maximum path length in OS/161?
What is the system call number for a reboot?
Where is STDIN_FILENO dened?
kern/lib
These are library routines used throughout the kernel, e.g., managing
sleep queues, run queues, kernel malloc, etc.
kern/main
This is where the kernel is initialized and where the kernel main
function is implemented.
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
10 of 17 14-07-23 04:33 PM
kern/thread
Threads are the fundamental abstraction on which the kernel is built.
Is it OK to initialize the thread system before the scheduler?
Why (not)?
What is a zombie?
How large is the initial run queue?
kern/userprog
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/vm
This directory is also fairly vacant. In Assignment 3, you'll implement
virtual memory and most of your code will go in here.
kern/fs
The le system implementation has two subdirectories. We'll talk about
each in turn.
kern/fs/vfs
This is the le-system independent layer (vfs stands for "Virtual File
System"). It establishes a framework into which you can add new le
systems easily. You will want to go look at vfs.h and vnode.h before
looking at this directory.
What does a device name in OS/161 look like?
What does a raw device name in OS/161 look like?
What lock protects the vnode reference count?
What device types are currently supported?
kern/fs/sfs
This is the simple le system that OS/161 contains by default. You can
ignore this directory for now.
Building a Kernel
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
11 of 17 14-07-23 04:33 PM
Now it is time to build a kernel. As described in kern/conf, you will need to
congure a kernel and then build it.
Congure your tree for the machine on which you are working. 1.
% cd ~/ece344/os161
% ./configure --ostree=$HOME/ece344/root
% make
This will build and create the various les needed to run your kernel and
put them in $HOME/ece344/root
Congure a kernel named ASST0. 2.
% cd ~/ece344/os161/kern/conf
% ./config ASST0
This will create the ASST0 build directory in kern/compile. The next step will
actually build a kernel in this directory. Note that you should specify the
complete pathname ./config when you congure OS161. If you omit the ./,
you may end up running the conguration command for the system on
which you are building OS161, and that is almost guaranteed to produce
rather strange results!
3.
Build and install the ASST0 kernel.
% cd ../compile/ASST0
% make depend
% make
% make install
4.
Note that if you make any changes to your kernel, you only need to repeat
step 4 to install the new kernel. However, if you modify or add test
programs to the ~/ece344/os161/testbin directory, you will need to run make in
the top level directory to make and install the new les from testbin.
Running your kernel
Change to your root directory. Copy the default simulator conguration le
into the root directory.
% cd ~/ece344/root
% cp /local/packages/cs161/bin/sys161.conf.sample sys161.conf
You should take a look at this le, as it describes how to congure the
simulator you will be running your code in.
1.
Run the machine simulator on your operating system.
% sys161 kernel
2.
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
12 of 17 14-07-23 04:33 PM
At the prompt, type p /sbin/poweroff<return>. This tells the kernel to run
the poweroff program that shuts the system down.
3.
Adding Debugging Statements
Program instrumentation is a common debugging technique where printf()
statements (or in the case of kernel code, kprintf()) are added at various points
in the code to output information about the program's running state. Instead of
adding printf() statements directly, it is often convenient to use macros that
allow instrumentation to be turned on and o easily.
Examine the DEBUG macro in kern/include/lib.h. Based on your earlier reading of
the operating system, add ve useful debugging messages to your operating
system. Be sure to add the debugging messages to various parts of the kernel;
they should not all be in the same le.
From reading the code and comments, try to gure out how to enable and
disable these DEBUG macros. In general, debugging operating systems code is
far more diicult than debugging regular code. To save your sanity, please refer
to the 10 Commandments of OS161 programming.
Adding System Calls
A large component of Assignment 0 is adding the following system calls to
OS/161:
int _helloworld(void)
This system call is handled by having the kernel print "Hello World\n" using
the internel kprintf() function. It takes no arguments but returns the return
value from kprintf to the user level. You will need to understand how to add
a new system call number, and build the user and kernel sides of the
interface. Study the existing reboot() system call to get started.
1.
int _printint(int value)
This system call passes an integer to the operating system kernel, where it
is printed out using the kprintf function. Only print the integer. Notably, do
not print a newline after the number. The return value should be the return
value from kprintf.
2.
int _printstring(char *string, int numchars)
This system call passes a pointer to a string to be printed, and a number of
characters to print. The kernel must rst copy the string from the user
address into a kernel buer, and then print it using kprintf. Your code must
3.
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
13 of 17 14-07-23 04:33 PM
be careful to check for misuse by the user (for example, the memory
pointed to by "string" may not contain a proper null-terminated string of
length numchars). If an error is detected, errno should be set and an
appropriate result returned. Otherwise, the return value should be the
return value from kprintf.
Notice that the system calls include a leading underscore ("_"). This is part of the
system call name and is how user level programs will use the system call. (see
the User Level Test below).
You will need to modify the code in kern/arch/mips/mips/syscall.c to detect your new
system calls and dispatch appropriate system call handlers. Although these
system calls are simple enough to implement full within syscall.c, it is good
programming practice to put the handlers in a separate function in a le in the
kern/userprog subdirectory. You should name this le simple_syscalls.c.
Please read the document Understanding System Calls for additional information
about how user-level programs are started from the OS/161 kernel, and how
system calls operate on both the system and user side of the interface. This
document also describes how to test your new system calls.
Note that after adding a new le to the kernel source, itis necessary to
recongure the ASST0 kernel before building and installing it. Examine the
documentation at the top of the cong script (~/ece344/os161/kernel
/conf/cong). Then edit the ASST0 cong le and rebuild the conguration:
% cd ~/ece344/os161/kern/conf
% vi ASST0
% ./config ASST0
Testing Your New System Calls
Quick Sanity Check
As a quick test you can modify kern/main/main.c and add a call (in a suitable place)
to helloworld(). Build your kernel again. Make sure that your new kernel runs
and displays the new message. Note that if you add new les to your kernel
source tree, you have to modify and enter them in the build conguration using
the "le". command. Consult kern/conf/conf.kern for more documentation on how
to do this.
User Level Tests
The above test does not check if your system calls are callable from a user level
(as opposed to kernel level) program. To test this, add new test programs to
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
14 of 17 14-07-23 04:33 PM
src/testbin. Use the existing programs as a template. For example, the following
commands will make a copy of an existing program in testbin:
% cd ~/ece344/os161/testbin
% mkdir syscalltest
% cp argtest/argtest.c syscalltest/syscalltest.c
% sed 's/argtest/syscalltest/' argtest/Makefile > syscalltest/Makefile
% touch syscalltest/depend.mk
Now modify syscalltest/syscalltest.c to call your new system calls. You could use
the following program to test the "_helloworld()" system call:
#include <unistd.h>
int main()
{
_helloworld();
return 0;
}
Modify testbin/Makefile to add an entry for the new syscalltest directory.
Build and install the syscalltest program:
% cd ~/ece344/os161/testbin/
% make
% make install
Now run the syscalltest program by starting the os161 kernel, and entering p
/testbin/syscalltest from the kernel prompt.
One nal note: All user programs end by calling the "_exit" system call, even if
your main() function does not end with the C library exit() function. The _exit
system call isn't implemented yet, and you are not required to implement it for
this assignment. Without it, however, you will trigger the "default" case in
mips_syscall when your test programs nish. The default case simply prints that
the system call is not implemented.
For the time being, you can if you wish, implement the _exit system call (similar
to how you implemented the _helloworld system call). Basically, you need to add
a case into syscall.c to handle the _exit system call. The implementation of this
system call can simply call thread_exit. A common mistake is to call thread_exit
from a user program. This is incorrect, since thread_exit is supposed to only be
accessible from the kernel, not from user programs.
Again, implementing the _exit system call is an optional task for this
assignment.
Sample Test Cases
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
15 of 17 14-07-23 04:33 PM
Your syscalltest program should call the new syscalls with various inputs, and
verify that the return values and output are correct. Here are some test cases to
get you started:
Call: _helloworld()
Output: Hello World\n
(Note this is a Hello World string followed by a newline character, not Hello
World followed by \ and n characters.)
Return value: 12 (the number of characters printed)
Call: _printint(88)
Output: 88
Return value: 2
Call: _printint(-1)
Output: -1
Return value: 2
Call: _printstring("Hello",5)
Output: Hello
Return value: 5
Call: _printstring("Hello",3)
Output: nothing
Return value: an appropriate error value
Call: _printstring("Hello",-10)
Output: nothing
Return value: an appropriate error value
Preparing your assignment for submission
Finally, you need to prepare your code for submitting your assignment.
Once you are condent that you have completely done your assignment, run
svn commit from the os161 directory so that all modied les are checked in
your repository. Before running commit, you may have to add new les to
the repository using svn add. Please refer to the SVN document for more
details. Use svn status in the os161 directory to make sure that all your
modied source les are properly committed.
1.
Tag your repository for the end of asst0:
% svn copy $ECE344_SVN/trunk $ECE344_SVN/tags/asst0-end
Remember the tags directory we created earlier? This is versioned like any
2.
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
16 of 17 14-07-23 04:33 PM
other part of your SVN repository. The step above simply copies from /trunk/
into tags/asst0-end. It's also repeatable, so if you realized later you have
changes yet to commit you can repeat the copy using a new version of
/trunk/.
What to submit for prep:
Finally, create a patch that describes the changes you have made in this
assignment:
% svn diff $ECE344_SVN/tags/asst0-start $ECE344_SVN/tags/asst0-end > asst0.patch
1.
Submit the patch le.
% submitece344f 0 asst0.patch
2.
2011David Lie - all rights reserved. Last modied: 2011-09-19
Assignment 0: Introduction to OS161 http://www.eecg.toronto.edu/~lie/Courses/ECE34...
17 of 17 14-07-23 04:33 PM