Subversion Repositories HelenOS-doc

Compare Revisions

Ignore whitespace Rev 41 → Rev 42

/prjdoc/trunk/prjdoc.tex
5,7 → 5,6
\usepackage{fancyhdr}
%\pagestyle{fancy}
 
 
\title{
\Huge{\bf HelenOS project}\\
\LARGE{\it project documentation}
14,6 → 13,7
 
\newcommand{\JJ}{Jakub Jerm\'{a}\v{r}}
\newcommand{\OP}{Ond\v{r}ej Palkovsk\'{y}}
\newcommand{\Ondrej}{Ond\v{r}ej}
\newcommand{\MD}{Martin D\v{e}ck\'{y}}
\newcommand{\JV}{Jakub V\'{a}\v{n}a}
\newcommand{\JC}{Josef \v{C}ejka}
/prjdoc/trunk/tools/tools.tex
173,6 → 173,12
troubleshooting. Moreover, part of the simulators featured integrated debugging facilities.
Without them, a lot of bugs would remain unresolved or even go unnoticed.
 
Using several virtual environments for testing one architecture is well justified by the
fact that sometimes HelenOS would run on two and crash on third or vice versa. Sometimes
we found that it runs on real hardware but fails in a simulator. The opposite case was,
however, more common. Simply put, the more configurations, no matter whether real or virtual,
the better.
 
From one point of view, we have tested our system on eight different virtual environments:
 
\begin{itemize}
210,7 → 216,10
(patch \#1282033).
 
Bochs has some debugging facilities but those have been very impractical and broken
in SMP mode.
in SMP mode. Moreover, it is possible to use the GNU debugger {\tt gbd} to connect to running
simulation, but this has also proven not very useful as we often needed to debug
problems that existed only in multiprocessor configurations, which {\tt gdb}
does not understand.
 
\subsection{GXemul}
GXemul is an emulator of several processor architectures. Nevertheless, we have
251,6 → 260,11
which was nice for those of us who use notebooks as their development
machine.
 
Similar to Bochs, QEMU simulation can be aided by {\tt gdb}. Debugging
with {\tt gdb} can be pretty comfortable\footnote{Especially when the kernel is
compiled with {\tt -g3}.} until one needs to debug a SMP kernel running on multiple
processors.
 
\subsection{Simics}
Virtutech's Simics simulator can be compared to a Swiss-army knife for operating system debugging.
This proprietary piece of software was available to us under an academic license for free.
295,12 → 309,12
make it far enough for the HP to fix or at least clarify the issue. Finally, we adopted a workaround implemented by {\JJ}
that simply swaps LMA and the program entry point in the kernel ELF image.
 
\subsection{VMware}
VMware is the only virtualizer we have used in HelenOS development. It virtualizes the ia32 host machine.
Since VMware version 5.5, we made use of its possibility to run the guest system (i.e. HelenOS) on multiple processors.
VMware has no support for debugging but is very useful for compatibility and regression testing because
it's closest to the real hardware. VMware, being a virtualizer, is also the fastest of all the virtual environments
we have utilized.
\subsection{VMware} VMware is the only virtualizer we have used in
HelenOS development. It virtualizes the ia32 host machine. Since VMware
version 5.5, we made use of its possibility to run the guest system
(i.e. HelenOS) on multiple processors. VMware has no support for
debugging but is very useful for compatibility and regression testing
because it's closest to the real hardware. VMware, being a virtualizer,
is also the fastest of all the virtual environments we have utilized.
 
 
\section{Authoring tools}
/prjdoc/trunk/project/project.tex
6,6 → 6,7
SPARTAN kernel\footnote{The SPARTAN kernel has been developed by {\JJ}
since 2001.} as a foundation for their new operating system.
 
\section{Specification}
The team had then worked on a specification\cite{helenos-spec} until
March 8, 2005. The specification was based on \MD's draft and
incorporated many suggestions from other members of the team. The
37,11 → 38,37
was also an optional part comprising of three research or experimental
topics. We hoped to eventually find time to work on them.
 
\section{Project meetings}
After adopting our specification, we started to meet regularily every two weeks
for the sake of consultations. The regular meetings were cancelled only during
the exam periods and summer holiday. The first meeting took place on April 28,
April. There had been twenty project meetings before 1.0.0 release.
April. There had been exactly twenty three project meetings before 1.0.0 release.
 
The Faculty of Mathematics and Physics officially opened our project on June 10,
2005.
2005. However, serious collective work on the project, preceeded by individual
efforts of some team members, began two months later.
 
\section{Planning work}
In the beginning, we structured our work by creating three two-member teams,
each dedicated to one new architecture (i.e. amd64, ia64 and ppc32). However,
dividing into couples didn't work out for the amd64 and ppc32 teams. In the end,
both of those architectures were supported only with one member of respective
team. This might have been because of two factors. First, the collective responsibility
for the project allowed the less motivated members to work less than others.
Second, over the time, some developers profiled out to be good at specific tasks to which
they later adhered and were forwarded more similar work. It was generally accepted
within the team if one of the couple traded one architecure-specific task for another task
on HelenOS.
 
\section{Kernel camps}
There were two really important moments in our development process. Both of them
took place in Harrachov, Czech Republic, where five team members moved two times, each
time for a week of full-time intensive HelenOS development. These actions were
called Kernel Camp 2005 and Winter Camp 2006. The former camp took place in August 2005
and was focused on getting all the architectures into our source tree and deepening
their support. The latter camp took place in March 2006 and was dedicated to userspace
support. In fact, we made the second camp the deadline for userspace milestone. With the
exception of ppc32, all ports had some support for userspace prior to the second camp.
Both of the camps moved the project miles ahead.
 
 
/prjdoc/trunk/developers/developers.tex
2,65 → 2,62
\label{developers}
 
\section{\JJ}
{\JJ} is the original author of the SPARTAN kernel and the initiator of the
idea to start the HelenOS project. During the works on the system, he has
been the most active developer. He also took on the project agenda
and administration and became the project leader.
Jakub is the original author of the SPARTAN kernel and the initiator of
the idea to start the HelenOS project. Once the team was composed, he
implemented considerable parts of the ia64 code and he also worked on
the mips32 memory management. On the generic front, Jakub designed the
generic virtual address translation interface for the 4-level
hierarchical page table translation mechanism as well as the global page
hash table translation mechanism. He has been involved in the address
space management functions and userspace synchronization through
futexes. Other areas in which he contributed include the kernel console
and the kernel ELF loader. Jakub is also the author of the generic buddy
system framework as well as the B+tree implementation. His latest
contribution is the userspace PCI driver.
 
Before the project officially started, {\JJ} created the SPARTAN kernel
for ia32 and mips32 along with SMP support, scheduler and synchronization\footnote{The
initial SPARTAN kernel did not reach userspace.}.
 
In the project time proper, he implemented considerable parts
of ia64 code and worked also on mips32 memory management.
On the generic front, {\JJ} designed generic the virtual address
translation interface for the 4-level hierarchical page table translation mechanism
as well as for the global page hash table translation mechanism. He has been involved
in address space management functions and userspace synchronization through futexes.
Other areas of his contribution include the kernel console and the kernel ELF loader.
{\JJ} is also the author of the generic buddy system framework and B+tree implementation.
 
\section{\OP}
{\OP} has been very agile HelenOS developer. He is responsible for large areas of the
kernel and userspace and has completely created the amd64 port and completed the mips32
port to the extent that it runs on a real MIPS machine\footnote{SGI Indy}.
Besides the architecture specific involvement, {\OP} programmed the slab allocator
and modified the frame allocator to be self-contained which in turn let the old
and very limited heap manager be removed from the kernel entirely. He also created
architecture independent FPU lazy switching framework. Other example of his
activity is the IPC subsystem and partial TLS\footnote{Thread local storage.} support.
Lastly, {\OP} equipped the kernel console with features found in userspace command shells
(e.g. tab completion of commands and command history through keyboard arrows) and wrote
the kernel configuration software.
{\Ondrej} has completely created the amd64 port and completed the mips32 port
to the extent that it runs on a real MIPS machine\footnote{SGI Indy}.
Besides the architecture specific involvement, {\Ondrej} programmed the slab
allocator and modified the frame allocator to be self-contained which in
turn let the old and very limited heap manager be removed from the
kernel entirely. He also created architecture independent FPU lazy
switching framework. Other example of his activity is the IPC subsystem
and partial TLS\footnote{Thread local storage.} support. Lastly, {\Ondrej}
equipped the kernel console with features found in userspace command
shells (e.g. tab completion of commands and command history through
keyboard arrows) and wrote the kernel configuration software.
 
Apart from the self development, other members of the team appreciated \OP's excellent
debugging and troubleshooting skills. He has been the person behind discovery of
majority of the compiler and simulator bugs.
 
\section{\MD}
{\MD} is a very dedicated HelenOS developer. Right from the beginning, Martin
has cared about project's code purity and readibility. He was the first developer to
start writing Doxygen-style comments. He has promoted the proper use of C language
{\tt const} keywords and extensive typedefing. On the tools front, he has rewritten
the initial build system and created all our toolchain build scripts.
Right from the beginning, Martin has cared about project's code purity
and readibility. He was the first developer to start writing
Doxygen-style comments. He has promoted the proper use of C language
{\tt const} keywords and extensive typedefing. On the tools front, he
has rewritten the initial build system and created all our toolchain
build scripts.
 
Martin worked and much improved the ia32 and amd64 kernel booting using the Grub bootloader
and Multiboot specification. He also created specialized boot loaders for mips32 and ppc32 --- architectures
that don't provide many other ways to load userspace init tasks. Finally,
{\MD} bacame the sole author of the entire ppc32 port and has encountered
partial success in booting ppc64 port to real hardware\footnote{Apple G5.}.
Martin worked and much improved the ia32 and amd64 kernel booting using
the Grub bootloader and Multiboot specification. He also created
specialized boot loaders for mips32 and ppc32 --- architectures that
don't provide many other ways to load userspace init tasks. Finally,
Martin bacame the sole author of the entire ppc32 port and has
encountered partial success in booting ppc64 port to real
hardware\footnote{Apple G5.}.
 
\section{\JV}
{\JV} has worked on ia32 and ia64 FPU context switching and passive ia32
and active and passive ia64 console. He has relocated the ia64 kernel to
region 7 (i.e. to the highest addresses) and has first coped with ia64
interrupts. {\JV} has been always prepared to discuss different kernel
issues. His expertise in ia32 is well recognized.
Jakub has worked on ia32 and the ia64 FPU context switching and passive
ia32 and active and passive ia64 console. He has relocated the ia64
kernel to region 7 (i.e. to the highest addresses) and has first coped
with ia64 interrupts. Lastly, Jakub programmed the VESA frame buffer
support for ia32 and amd64 and created the userspace framebuffer driver.
 
\section{\JC}
{\JC} has worked on ia32 memory map detection, softfloat and softint libraries
and printf() standards comformance. He also ported several kernel libraries to userspace.
Josef has worked on ia32 memory map detection, softfloat and softint
libraries and printf() standards conformance. He also ported several
kernel libraries to userspace and implemented considerable parts of
HelenOS libc. Josef is the author of the userspace keyboard driver.
 
\section{\SB}
{\SB} implemented sorting library functions and implemented the buddy allocator
interface for the frame allocator. He edited project documentation.
Sergey implemented sorting library functions and implemented the buddy
allocator interface for the frame allocator. He edited project
documentation.