In the summer of 2005, I
wanted to develop a small operating system to use as the basis for
future research and education. I was joined by our resident research
engineer, Gary Wong, who has proven invaluable during the course of
this work. Together we wrote the beginnings of "Quest",
a relatively simple operating system having a shell, basic device
support, fork/exec/exit process control semantics, simple preemptive
scheduling, coroutine and paging capabilities. The current version of
Quest works on the Intel IA32 family of processors and includes
a stripped down system library (containing, for the most
part, a subset of the libc functionality, including malloc/free
routines for dynamic memory allocation).
We have currently written several test applications for Quest,
including a couple of "interesting" ports of existing programs: one
being the classic PDP-10 text adventure called "advent" (originally
written in Fortran but now available in C), and another being the
classic arcade game "pacman".
Here is a screen shot of the Quest shell running the "advent"
text adventure game (ported from the C version originally written by
Don Woods). The Bochs PC emulator is being used in this example but we
have verified the code works correctly on the bare hardware:
Here is a screen shot of Quest running pacman in a modified VGA
resolution (hence the reshaped window under Bochs):
The Future?
So far Quest has similar functionality to the original Linux
system version 0.0.1, by Linus Torvalds. Fundamentally, we rely on more
hardware support than Linux (at least in recent Linux versions) by
using hardware-controlled task-switching and "nested tasks". In the
latter case, this enables us to define certain tasks that can be
invoked (e.g., via call gates) to execute outside the core kernel. Such
nested tasks can be used, as is currently the case, to implement
various
system services (e.g., a terminal server). We have leveraged Linux's
ext2 file system but we do not currently have much in the way of
functionality beyond that needed to mount a file system partition, open
and read files. This is an area of future development.
Because of the relative simplicity of the code, and the
correspondingly small footprint, we intend to use Quest in the
classroom as a method for teaching operating system concepts. Several
other relatively small systems have already proved useful for
educational purposes, such as GeekOS, Nachos, and Minix. While we
have some features in common with these systems, we also intend to use
our system for research (e.g., (a) to see how it can
be used in embedded systems as well as more general computing
environments, (b) how the system can be structured to safely and
predictably meet the requirements of end users, and (c) to test out
various policies and mechanisms for resource management).
Amongst other objectives are the desire to benchmark research
ideas on a working system without having to resort to "less realistic"
simulations. It is worth noting that the name "Quest" was originally
coined to capture the notion of a system that could meet the QoS
requirements of users while supporting application-specific
(extensible) services. How the system is structured to achieve service
requirements of end users is of particular interest.
Further Information
A brief overview of the basic design of Quest can be found here.
