Project 1

CMSC 412, Fall 2005

Due Tuesday, September 20, at 6pm

Note: Project spec revised. 09/19. Changes are highlighted in red


In this project we will be augmenting the GeekOS process services to include (1) background processes, (2) being able to kill a process asynchronously from another process, and (3) being able to view the currently running processes and their status.

Quick Links


We will first provide some background on how processes are implemented in GeekOS, and how processes use system calls to request kernel services.  The project requirements are presented below.

Address Space Protection

To prevent one process from accessing another process's memory, or from accessing memory belonging to the kernel, most operating systems, including GeekOS, implement processes as having their own address space.  In particular, instructions issued within a process may not refer to physical memory addresses, but rather only to logical addresses, which are essentially one or two levels of indirection removed from the underlying memory address.  The kernel is responsible for setting up a process's logical address space when it creates the process---that is, what logical addresses map to what physical addresses---and thus it can control what memory a process can access.  If the process attempts to access memory outside of its logical address space, the hardware will generate an interrupt, and the OS can then kill the process.  GeekOS currently uses segmented memory to implement user process address spaces. This is a facility provided by the Intel hardware, and we will explain it in more detail below.

System Calls

Sometimes a program will need to interact with the system in ways that require it to access other memory, or otherwise perform privileged operations. For example, if the program wants to write to the screen, it may need to access video memory, which will be outside of the process's segment.  Or it may need to use privileged instructions, such as I/O instructions, that only the OS can perform on its behalf. 

The operating system therefore provides a series of System Calls, also known as Syscalls, which are routines that carry out some operation for the user process that calls it. But since these routines are themselves in protected memory, the OS provides a special mechanism for making syscalls.

In order to make a syscall in GeekOS, a user program sends a processor interrupt, using the int instruction. GeekOS has provided an interrupt handler that is installed as interrupt 0x90. This routine, called Syscall_Handler (src/geekos/trap.c), examines the current value in the register eax and calls the appropriate system routine to handle the syscall request. The value in eax is called the Syscall Number. The routine that handles the syscall request is passed a copy of the caller's context state, stored in struct Interrupt_State, so the values in general registers (ebx, ecx, edx) can be used by the user program to pass parameters to the handler routine and can be used to return values to the user program.

The syscall routines are defined in src/geekos/syscall.c: Sys_Null, Sys_Exit, etc.  In general, syscall routines will do the following:

Before returning from the syscall, some OS code must restore the user context so that the program can continue running where it left off. A pointer to the stored copy of the context - on the kernel stack - is actually what is passed to the Syscall_Handler.

Further Reading: More information about system calls more generally can be found in Chapter 2 of the text.

User vs. Kernel Memory

The user process and the kernel both access main memory, but addresses in user space and addresses in kernel space to the same memory will be different, because each has its own distinct logical address space.  This means that any user address passed to the kernel via a system call will need to be mapped to a kernel address before the kernel can properly access the memory.  The kernel therefore uses the routines Copy_From_User and Copy_To_User to copy data to and from user memory, and these routines properly map user addresses to kernel ones.

While it is easy to use these routines (you can look at existing system calls for examples), it is harder to understand how they work, because it requires understanding how GeekOS uses the x86 memory segmentation system to implement kernel and user process address spaces.  This is a good time for you to start figuring this out; you will have to understand it in intimate detail to successfully complete project 4.


Memory Segments. The facility that the processor provides for dividing up memory is its handling of memory segments. A memory segment specifies a region of memory and the "privilege level" that is required to access that memory. Each user program has its own memory segments - one for code, one for data, one for its stack, plus a couple extra for various purposes. If the operating system sets up the segments properly, a program will be limited to accessing only its own memory.

Privilege levels range from 0 to 3. Level 0 processes have the most privileges, level 3 processes have the least. Protection levels are also called rings in 386 documentation. Kernel processes in GeekOS run in ring 0, user processes run in ring 3. Besides limiting access to different memory segments, the privilege level also determines the set of processor operations available to a process. A program's privilege level is determined by the privilege level of its code segment.

If a process attempts to access memory outside of its legal segments, the result should be the all-too-familiar segmentation fault, and the process will be halted.

Another important function of memory segments is that they allow programs to use relative memory references. All memory references are interpreted by the processor to be relative to the base of the current memory segment. Instruction addresses are relative to the base of the code segment, data addresses are relative to the base of the data segment. This means that when the linker creates an executable, it doesn't need to specify where a program will sit in memory, only where the parts of the program will be, relative to the start of the executable image in memory.

Descriptor Tables.  The information describing a segment---which is logically a base address, a limit address, and a privilege level---is stored in a data structure called a segment descriptor. The descriptors are stored in descriptor tables. The descriptor tables are located in regular memory, but the format for them is exactly specified by the processor design. The functions in the processor that manipulate memory segments assume that the appropriate data structures have been created and populated by the operating system. You will see a similar approach used when you work with multi-level page tables in project 4.

There are two types of descriptor tables. The Local Descriptor Table (LDT) stores the segment descriptors for each user process. There is one LDT per process. The Global Descriptor Table (GDT) contains information for all of the processes, and there is only one GDT in the system. There is one entry in the GDT for each user process which contains a descriptor for the memory containing the LDT for that process.  This descriptor is essentially a pointer to the beginning of the user's LDT and its size.

Since all kernel processes are allowed to access all of memory, they can all share a single set of descriptors, which are stored in the GDT.

The relationship between GDT, LDT and User_Context entries is explained in the picture below:

Segment Descriptor Selectors.  The GDTR and LDTR registers contain the addresses of the GDT and the current LDT, respectively. In addition, for fast access, there are six registers that keep track of a process's active segments:

These registers do not contain the actual segment descriptors. Instead, they contain Segment Descriptor Selectors, which are essentially the indices of descriptors within the GDT and the current LDT.

The memory segments for a process are activated by loading the address of the LDT into the LDTR and the segment selectors into the various segment registers.  This happens when the OS switches between processes.  If you like, you can follow the Schedule() call in src/geekos/kthread.c to see how this is done (this will require looking at some assembly code---beware!).

Further Reading:  For more information on this topic, please refer to the Intel Developer's Manual, Sections 3.1 to 3.5.  The book covers segmentation in Chapter 9.

Process Creation and Termination

As you already know, a user process in GeekOS is essentially a Kernel_Thread with an attached User_Context.  Each Kernel_Thread also has a refCount field that is used to indicate the number of kernel threads interested in this thread.  When a thread is alive, its refCount is always at least 1, which indicates its own reference to itself.  If a thread for a process is started via Start_User_Thread with a detached argument of "false", then the refCount will be 2: one self-reference plus a reference from the owner.  When detached is false, the owner field in the new Kernel_Thread object is initialized to point to the Kernel_Thread spawning it (aka the parent).   Typically, the parent of a new process is the shell process that spawned it.

The parent-child relationship is useful when the parent wants to retrieve the returned result of the new process using the Wait() system call.  For example, in the shell (src/user/shell.c), if Spawn_Program is successful, the shell waits for the newly launched process to terminate by calling Wait(), which returns the child process's exit code.  The Wait system call is implemented by using thread queues, which we explain below.

When a process terminates by calling Exit, it detaches itself, removing its self-reference.  Moreover, when the parent calls Wait, it removes the other reference, bring refCount to 0.  When this is the case, the Reaper process is able to destroy the thread, discarding its Kernel_Thread object.  Any process that is dead, but still has a reference count greater than 0 is called a zombie. Any process that is dead, but has not been reaped, is called a zombie.  That is, it is dead, but cannot yet be reaped by the reaper.  Typically this is because it is waiting for the parent to call Wait to extract its exit code and decrement its final refCount.

More about process lifetimes: Zombies (New)

A process can be in one of four states on its way from being alive to being dead:
  1. refCount=0, alive=false

    In this case, it's a zombie thats' "totally dead," as the child has done Exit to reduce its refCount, and if it had a parent at all, it reduced its refCount too. Thus, the process will soon be reaped.

  2. refCount=1, alive=false

    In this case, the process has done Exit(), but the parent hasn't done Wait(). In this case, the process is also a zombie, but is not on the graveyard queue.

  3. refCount=1, alive=true

    In this case, the process is a background process, and is alive and well.

  4. refCount=2, alive=true

    In this case, the process is a foreground process, and is alive and well.

Thread Queues

As processes enter the system, they are put into a job queue. In particular, the processes that are residing in the main memory and are ready and waiting to execute are kept on a list called the run queue.  It stays there, not executing, until it is selected for execution. Once the process is allocated the CPU and is executing, one of several events can occur:

In the first two cases, the process eventually switches from the waiting state to the ready state and is then removed from its I/O queue and put back in the run queue. A process continues this cycle until it terminates, at which time it is not present on any queue.

Project Requirements

There are three primary goals of this project:

Add background processes

As explained above, in order for a process to be reaped, a parent must Wait() on the child process's pid.  However, there may be situations in which the parent would like to let the child process just complete on its own and die a graceful death, without having to Wait() on it.  To do this, we need a way to spawn a child "in the background," so that the parent can continue on with its work, oblivious of what the newly spawned process is doing.  To implement background processes, do the following:

Killing of background processes

It could be that once a background process, or any other process, starts to run, it may behave badly, or the work it is performing may become irrelevant.  Therefore, we would like to have some way for one process to kill another process.  To do this, do the following:

Printing the process table

Now that we can run many processes from the shell at once, we might like to get a snapshot of the system, to see what's going on.  Therefore, you will implement a program and a system call that prints the status of the threads and processes in the system:


There is a Cyclone-enabled kernel available for this project, if you want to try it out (see the bullet list at the top of this description).  Basically you need to include Cyclone 0.8.2a binaries in your path; on linuxlab this is /afs/csic/projects/cmsc412/cyclone-0.8.2a/bin.  To use Cyclone for user-space programs, you will need to #include Cyclone-compliant versions of the GeekOS headers; we use Cyclone's buildlib tool to generate these during the build process.  Take a look at src/user/cyctest.cyc for an example.  Try porting shell.c to Cyclone (this may be part of a future project ...).  To use Cyclone as part of the kernel, you'll need to be careful about how Cyclone calls C code, and vice versa.  Look at last Fall's project 0 spec for more information.

Web Accessibility