General-purpose and portable operating system with elements of
microkernel design and fully preemptive kernel.
SPARTAN kernel created by Jakub Jermar will be used as a basis for
further kernel development.
Detailed description of the features:
\begin{itemize}
\item General-purpose: Ready to run standard (non real-time) server and workstation applications. Support for common programming
abstractions (threads, synchronization, physical and virtual
memory management).
\item Portable: Except small platform-specific kernel parts the system will be implemented in higher programming languages to be portable
to different hardware platforms (PCs and similar).
\item Fully preemptive kernel: The basic scheduling element will be a thread (more threads eventually grouped into a task) and the task
switching will be preemptive in both user-space and kernel-space.
However no real-time scheduling will be attempted.
\item Fine grained locking in kernel: The kernel will not contain anything such as "big kernel lock", all critical sections will be
handled with small granularity locking.
\item Elements of microkernel design: The code running in kernel-space will be limited to a much smaller size compared for example to the
traditional Unix design. The kernel will contain mostly just the
code which is necessary to run in kernel-space (scheduling, memory
management and protection, hardware resource management, IPC).
Device drivers, filesystems, network stacks, etc. will be
implemented in user-space.
\end{itemize}
{\em The overall conecption of the kernel design was completely met. The kernel
is fully preemptible, SMP ready with fine-grained locking. If possible,
device drivers are implemented as standalone userspace tasks. HelenOS
fully supports statically linked tasks. Both userspace tasks and kernel
tasks are supported (N:M multithreading model).
The kernel was successfully ported to 5 architectures with one other
architecture to come. The interfaces in the kernel are designed in such
a way to fully utilize specifics of every platform, e.g. ASID and RID
allocation in MIPS and IA64, two stacks for IA64 and SMP routines.
}
Following features can be eventually implemented as research subjects,
but are optional to the overall design of the system:
\begin{itemize}
\item Kernel-level virtualization: Apart from some standard security model (i.e. unix-like or any other) the OS might support
kernel-level context separation allowing to run more virtual
operating environments on a single physical machine.
{\em Kernel-level virtualization was not attempted, although the microkernel
design by itself allows completely different namespace simply by connecting
the task to different name service daemon. Because new IPC connections can
be created only through existing paths in the graph of the connections,
messages can never flow between unconnected components of the graph.
}
\item Framework for running GNU/Linux applications: There should be no syscall or native API compatibility, but rather some kind of
compile-time layer (libc and other shared libraries) allowing to
compile common GNU/Linux applications from sources.
{\em Two applications were ported with little effort - libpci and tetris. The
porting of the tetris consisted mainly in rewriting termios dependent
code. The libc library contains emulation layer for the most common functions.}
\item Object/message paradigm: In the contrary to Unix file paradigm (where every object in the system is represented by a file - even
if there is no consistent mapping from the given object's methods
to generic file methods), HelenOS might have a tree of objects
instead of a tree of files. Each object in the tree can support an
arbitrary set of messages and files are those objects which
support the set of messages representing file methods (i.e. open,
close, read, write, seek, etc.). All objects might support several
compulsory messages (GetName, GetSupportedMessages, etc.). The
message passing mechanism will be synchronous.
{\em Every IPC message contains a field that specifies method number. However,
tree of objects or any more complex functionality were not implemented. }
\end{itemize}
{\em However, because we have decided to use asynchronous message passing,
a framework was needed to facilitate reasonably synchronous application view.
This framework, heavily using userspace thread switching, allows writing
transparent applications without the hassle usually connected with
asynchronous applications, at the same time being easily portable to
kernel-threaded environment. }
\begin{itemize}
\begin{itemize}
\item Preemptive multiprocessing, SMP support, threads (tasks) \begin{itemize}
\item Simple scheduler (but more complex than round-robin), with threads as basic scheduling element. {\em Achieved.}
\item Support for thread priorities (possibly classes of priorities for user-space tasks). {\em Achieved}
\item Support for SMP CPU bounding. {\em Achieved.} \item Utilization of non-boot CPU(s). {\em Achieved.} \item Support for user-space threads (tasks as sets of threads). {\em Achieved.}
\item Support for kernel threads (independent code executed within the kernel) {\em Achieved.}
\end{itemize}
\item Kernel synchronization primitives, small granularity synchronization (preemptive kernel)
\begin{itemize}
\item Semaphores, mutexes, condition variables, RW-locks, spin-locks, etc. {\em Achieved.}
\item No "big kernel lock". {\em Achieved.} \end{itemize}
\item Physical and virtual memory management \begin{itemize}
\item Proper handling of physical memory regions. {\em Achieved.}
\item Physical memory heap (allocating of continuous blocks of physical memory). {\em Achieved.}
\item Arbitrary number of independent virtual memory mappings (both for threads and internal kernel usage). {\em Achieved.}
\item Kernel allocator in virtual memory (buddy/slab). {\em Achieved.} \item Named (text, stack, heap) and unnamed virtual memory areas. {\em Achieved.}
\item Copying and sharing pages between different memory mappings. {\em Achieved.}
\end{itemize}
\item Basic hardware handling \begin{itemize}
\item Handling of basic boot-time hardware (CPU, PCI buses, memory, display, keyboard, RTC, etc.) in kernel. {\em Achieved.}
\item Handling of specific hardware resources which are fundamentaly unreachable from user-space on given
platform. {\em Achieved.}
\end{itemize}
\item IPC, user-space hardware access framework \begin{itemize}
\item Abstraction for implementing inter-process communication (message passing, etc.). {\em Achieved.}
\item Interface for enabling the user-space threads to gain access and manage hardware resources (with kernel
modules where needed). {\em Achieved.}
\end{itemize}
\item User-space features \begin{itemize}
\begin{itemize}
\item Memory management API (memory regions creation, descruction, resizing). {\em Achieved.}
\item Task/thread management API. {\em Achieved.} \item Synchronization API. {\em Futexes implemented.} \end{itemize}
\end{itemize}
\end{itemize}
\end{itemize}
\begin{itemize}
\item Supported platforms \begin{itemize}
\item Real hardware support \begin{itemize}
\item IA-32 (will be tested on multiple consumer Intel Pentium~4, Intel Pentium~M, AMD Athlon~XP and AMD Athlon~MP machines)
{\em Runs on comodity hardware. Tested on several multiprocessor computers.}
\item PowerPC (will be tested on a consumer IBM PowerPC G5 machine) {\em To some extent runs on the G4 machine. G5 machine is a 64-bit architecture completely different from 32-bit port that was attampted. }
\end{itemize}
\begin{itemize}
\item MIPS (will be tested in MSIM R4000 simulator) {\em Tested in msim, gxemul and partially in simics simulators. Booted kernel on SGI Indy, however no real hardware input/output support was attempted.}
\item IA-64 (will be tested in Ski simulator) {\em Tested in Ski simulator.}
\item AMD64 (will be tested in Simics simulator) {\em Tested on single-processor computer. Runs in simics, bochs and qemu simulators.}
\end{itemize}
\end{itemize}
\end{itemize}