The goal for this assignment is to implement
process management. Specifically, you need to implement the semantics of the
Xinu routines, resume() , suspend() , create() , kill(),
and resched() . In addition, you should write a procedure, prprint()
, that will print information about the processes that exist in the
system. You should do this by first printing all non-free entries in the
process table, and then printing the contents of the Ready list, and the
current process. You should print all available information about each process
in a neat and orderly fashion, and use the same format for all processes.
You can assume that create takes only integer
arguments. Instead of implementing processes directly on the hardware, you will
implement ``light weight processes'' within a heavyweight UNIX process- your
kernel routines and all the processes you create will execute as part of a
single UNIX process. Unlike the Xinu routines, your routines do not currently
need to worry about interrupts. However, do write your routines in a modular
fashion, since subsequent assignments will build on the ``micro kernel'' you
implement as part of this assignment.
One difference between your kernel and Xinu
is that the former will start executing the Unix main procedure while the
latter starts executing an assembly routine called start(), which in
turn calls the C routine, nulluser(), which then forks the process
executing the main procedure. (Look at the implementation of nulluser()
and sysinit() in Chapter 13 of the Xinu book to see how a single program
is transformed into an operating system.) Assume that the programmer provides a
special procedure called xinu_main() which corresponds to the main
routine in a Xinu program. The Unix main procedure, thus, initializes the
kernel state and then uses Xinu create() to fork a process executing xinu_main().
Also, while Xinu process management uses Xinu getmem() for allocating
memory, you can simply use Unix malloc(). It would
be safest to not de-allocate memory for reasons we will discuss in class, otherwise you may get core dumps. You
must ensure that the Unix process does not terminate as long as there is a
single Xinu process in the system. Otherwise, future assignments, in which Xinu
processes might be waiting for remote communication, will not work. This can be
achieved by making the null process execute an infinite loop.
Thus your implementation effort will involve
simply including Xinu code into a Unix process. The course home page includes a
pointer to the Xinu
source code , which you can include in your assignment. Your implementation
should run on the Intel architecture- therefore look at the Pentium version of
Xinu. The directories of interest in this assignment are the sys and h
directories. Since you are not implementing on top of the bare machine,
comment out all calls to disable and restore interrupts. You can search the web
for information about Pentium assembly language. Two links I found are: Ghoshal's notes and
Smoler's
notes . You should build on top of a Unix-based OS for the Intel
architecture- FreeBSD or Linux. Classroom,
swan and quartet are three time sharing systems providing such an OS. Use swan
and quartet only if classroom is unavailable or highly loaded. If you have more
convenient access to some other Unix PC, go ahead and use it. (You can cleanly
implement some but not all assignments on top of a Windows-based OS.)
You are free to choose whether you want to
follow the Xinu code structure. In particular, you are free to use C++ and
object-oriented concepts to implement the code. (You can use java’s Thread
package as a guide to how an O-O process interface may be designed.) If you do
so, you will get a deeper understanding of process management, which, in turn,
will help in future assignments, which build on this one. However, if you are
unfamiliar with object-oriented programming concepts you would like to use, do
not use this class to learn them. So many things can wrong in your coding that
you should not have to worry about overcoming new programming concepts. I have
suggested C++ over Java because it has better integration with the C-based OS
calls and assembly code.
When you get this assignment, we may not have
covered all the Xinu routines you need to implement. In the meantime, you can
implement and test the Xinu Queue routines, which you will need in this
assignment. You may also want to look ahead at the process management routines
so that you can get an early start.
For this and all other assignments, prefix
all Xinu system calls with "xinu_". Thus kill() of Xinu should be called xinu_kill()
in your system. This will distinguish them from Unix calls such as kill()
with the same name. If you do not do so, you will get subtle errors in future
assignments. Also, make sure you allocate a large stack space (say 4K)
for the processes you create, otherwise you will get subtle problems because of
stack overflow, resulting in core dumps.
For this and subsequent assignments, you are
free to discuss the machine, programming environment and high-level algorithms
with other students but you are required to code your programs individually.
You will be graded on both the OS functionality you implement and the test programs you create to demonstrate
the functionality. The test programs
will be graded on
When (a) and (b) conflict with (c), give
precedence to (c). To help you
interactively test the programs, Stefan Zota, the S06 TA, created a shell
program (http://www.cs.unc.edu/~dewan/242/s07/code/zota_shell/shell.html),
which you can use to both test and demonstrate the OS functionality. (It may
have bugs!) Since you don’t have timer-based context switching in this
assignment, you should use resched() directly to switch among Xinu processes.
For this and future assignments, make an
appointment with me to demonstrate your solution. I would like to use a google
spreadsheet to create a sign-up sheet, so if you don’t have it already, get a
gmail account.
Your submission should include the code you
write, the grading sheet for the assignment (posted on the web), and written
answers to the following questions:
1) Unlike the LSI implementation (discussed
in class), the Pentium implementation does not store the registers to be saved
in the context block. Where does it store them?
2) Unlike the LSI implementation, the Pentium
implementation does not store the PC in the register save area. The saved PC,
in the LSI implementation, is used to ensure (a) a new process starts correctly
(at the start of its procedure) and (b) control is transferred to the correct
location after a context switch. Explain how these two goals are achieved in
the Pentium implementation. (Hint: Compare the ctxsw and create in the two
versions.)