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.
We will first provide some
background on process lifetimes in GeekOS, and some
more details on how system calls are implemented. The project requirements are
presented bellow. Following the requirements, we present further background
material on how process address spaces are implemented, many details of which
are not important for this project, but will be more important for project 4
(so it might be useful to understand at least some of them now).
As you already know, a user
process in GeekOS is essentially a Kernel_Thread with an attached User_Context.
Each Kernel_Thread has a field alive that
indicates whether it has terminated (e.g., whether Exit()
has been called). In addition, a Kernel_Thread 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 has not
been reaped, is called a zombie. The reasons for this could be many, one
instance being the parent failing to release its refCount:
bug or otherwise.
A process can be in one of
four states on its way from being alive to being dead:
This process is a
zombie that's "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.
The process has
called Exit(), but the parent hasn't called Wait(). In
this case, the process is also a zombie, but is not on the graveyard queue.
The process is a
background process, and is alive and well.
The process is a
"foreground" process, and is alive and well.
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.
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
There are three primary goals
of this project:
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:
·
Modify the Sys_Spawn system call to expect an additional argument from
the user process, which is whether to spawn in the background or not. Remember--the
Sys_* functions take only one argument, an Interrupt_State,
so if you want to pass another argument, you'll need to modify the macro
defining the system call to put another value into the registers before INT
0x90 is called. A background process is one that starts life detached;
i.e., it has no parent, and thus its refCount starts
at 1. In addition, a background process, and all of its
child processes (even if spawned as "foreground" processes),
should not be allowed to read input characters. In particular, the GetKey system call should fail, returning -1. In turn, the Read_Line library routine callable from user programs
should return -1 if it fails to get a key. The shell should be modified to
handle this possibility (since it calls Read_Line). A
parent process will not be able to Wait on any process
it spawns in the background; the Sys_Wait system call
will return -1 (or some more descriptive/appropriate negative value) in this
case. Note, however, that there is no restriction on background processes
spawning, and waiting on, foreground processes (which according to the
above-mentioned restriction should not be able to read input).
·
Modify the src/user/shell.c to handle forking processes in the
background. Modify the code to parse a command to look for '&' as the last
character, and if so, adjust the call to Spawn()
accordingly. Finally, the shell should print [PID] after it spawns a background
process, where PID is the process ID of the spawned process. For example, a
background spawn of the process "null.exe" at the shell would look
something like the following:
$ null.exe &
[10]
$
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:
·
Implement the Sys_Kill()
system call (a stub appears in src/geekos/syscall.c)
that takes a PID as its argument. The semantics are that the given process is
killed immediately. (Note that this is unsafe in a general setting, since that
process might hold shared resources, but there aren't any shared resources in GeekOS. Wait until project 3!).
This is different
from a thread calling Exit(). Note that when a thread
is executing it is not in any queue and is only referenced in g_currentThread. Therefore when doing the cleanup of a
thread that called Exit by itself it makes sense to not consider any queues.
But an asynchronous kill of a process can happen at any time. Particular
example scenarios are for instance when the process is waiting for its child
process to die and so is in the wait queue for that process. Or
when it is in the runQueue of the system.
Therefore when doing this asynchronous kill you will need to ensure that you
properly remove the process from all queues it is in.
Also consider what
should happen with a killed process's child processes: Their parent pointer is
now invalid, and so they should be adjusted accordingly. Indeed, the same thing
should happen for Exit, but does not in the implementation we provide---it
turns out that this field is not used by the child process after its parent
dies, so it can be left dangling. However, in your modified code, you will be
using the parent pointer to print the process table, so both Exit and Kill
should behave similarly, nulling the dangling parent
pointer.
There is an
interesting design point here: if a parent dies and fails to Wait()
on its children, should we also decrement the children's refCount?
If this does not happen, the child will remain a zombie, so decrement the
counter.
When determining
which processes can be killed; a process that falls in category II above (sec
"More about process lifetimes: Zombies") should be allowed to be
killed. This would happen because a child has died but its parent has not yet
done a Sys_Wait, and we want Sys_Kill
to be able to clean up the system nonetheless.
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:
struct Process_Info {
char name[128];
int pid;
int parent_pid;
int priority;
int status;
};