Subversion Repositories HelenOS-doc

Compare Revisions

Ignore whitespace Rev 155 → Rev 156

/prjdoc/trunk/spec/spec.tex
1,4 → 1,4
\chapter{Specification}
\chapter{Goals and Achievements}
 
\section{Overall Conception}
 
34,6 → 34,18
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,
44,10 → 56,22
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
58,7 → 82,16
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}
 
68,51 → 101,55
\item Preemptive multiprocessing, SMP support, threads (tasks)
\begin{itemize}
\item Simple scheduler (but more complex than round-robin),
with threads as basic scheduling element
with threads as basic scheduling element. {\em Achieved.}
\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)
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)
threads). {\em Achieved.}
 
\item Support for kernel threads (independent code executed
within the kernel)
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.
\item No "big kernel lock"
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
\item Proper handling of physical memory regions. {\em Achieved.}
\item Physical memory heap (allocating of continuous blocks of
physical memory)
physical memory). {\em Achieved.}
\item Arbitrary number of independent virtual memory mappings
(both for threads and internal kernel usage)
\item Kernel allocator in virtual memory (buddy/slab)
(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
areas. {\em Achieved.}
\item Copying and sharing pages between different memory
mappings
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
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
platform. {\em Achieved.}
\end{itemize}
\item IPC, user-space hardware access framework
\begin{itemize}
\item Abstraction for implementing inter-process communication
(message passing, etc.)
(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)
modules where needed). {\em Achieved.}
\end{itemize}
\item User-space features
\begin{itemize}
119,9 → 156,9
\item Basic API
\begin{itemize}
\item Memory management API (memory regions creation,
descruction, resizing)
\item Task/thread management API
\item Synchronization API
descruction, resizing). {\em Achieved.}
\item Task/thread management API. {\em Achieved.}
\item Synchronization API. {\em Futexes implemented.}
\end{itemize}
\end{itemize}
\end{itemize}
135,14 → 172,20
\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)
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}