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}
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.
\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.
\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.
\end{itemize}
\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
\item Support for thread priorities (possibly classes of priorities for user-space tasks)
\item Support for SMP CPU bounding \item Utilization of non-boot CPU(s) \item Support for user-space threads (tasks as sets of threads)
\item Support for kernel threads (independent code executed within the kernel)
\end{itemize}
\item Kernel synchronization primitives, small granularity synchronization (preemptive kernel)
\begin{itemize}
\item Semaphores, mutexes, condition variables, RW-locks, spin-locks, etc.
\item No "big kernel lock" \end{itemize}
\item Physical and virtual memory management \begin{itemize}
\item Proper handling of physical memory regions \item Physical memory heap (allocating of continuous blocks of physical memory)
\item Arbitrary number of independent virtual memory mappings (both for threads and internal kernel usage)
\item Kernel allocator in virtual memory (buddy/slab) \item Named (text, stack, heap) and unnamed virtual memory areas
\item Copying and sharing pages between different memory mappings
\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
\item Handling of specific hardware resources which are fundamentaly unreachable from user-space on given
platform
\end{itemize}
\item IPC, user-space hardware access framework \begin{itemize}
\item Abstraction for implementing inter-process communication (message passing, etc.)
\item Interface for enabling the user-space threads to gain access and manage hardware resources (with kernel
modules where needed)
\end{itemize}
\item User-space features \begin{itemize}
\begin{itemize}
\item Memory management API (memory regions creation, descruction, resizing)
\item Task/thread management API \item Synchronization API \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)
\item PowerPC (will be tested on a consumer IBM PowerPC G5 machine) \end{itemize}
\begin{itemize}
\item MIPS (will be tested in MSIM R4000 simulator) \item IA-64 (will be tested in Ski simulator) \item AMD64 (will be tested in Simics simulator) \end{itemize}
\end{itemize}
\end{itemize}