Subversion Repositories HelenOS-doc

\chapter{Goals and Achievements}

\section{Overall Conception}

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.

}

\section[1a]{Research Domains}

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. }

\section{Particular features}

\begin{itemize}

 \item Kernel features

       \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}

              \item Basic API

                    \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}

\section{Implementation details}

\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}

        \item Emulated support

              \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}