Subversion Repositories HelenOS-doc

Rev

Rev 36 | Rev 63 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
30 jermar 1
\chapter{Project}
33 jermar 2
\label{project}
3
 
36 jermar 4
The HelenOS project was formed in late October 2004, when the six
5
developers grouped and decided to adopt previous work of {\JJ} on the
6
SPARTAN kernel\footnote{The SPARTAN kernel has been developed by {\JJ}
7
since 2001.} as a foundation for their new operating system.
33 jermar 8
 
42 jermar 9
\section{Specification}
36 jermar 10
The team had then worked on a specification\cite{helenos-spec} until
11
March 8, 2005. The specification was based on \MD's draft and
12
incorporated many suggestions from other members of the team. The
13
biggest part of the discussion was concerned about how many and what
14
processor architectures we will support. At that time, the SPARTAN
15
kernel supported ia32 and mips32 to the extent that kernel threads could
16
be scheduled. The ia32 port could do some very basic virtual memory
17
operations and was capable of SMP service. Moreover, the mips32 port ran
18
only in the msim simulator. None of them supported userspace threads.
33 jermar 19
 
36 jermar 20
We realized the need to support at least one 64-bit architecture and
21
have long discussed whether it should be amd64 or ia64. We also considered
22
ppc64. At the end, we decided to declare support for three new architectures,
23
five architectures in total. Both amd64 and ia64 made it to the specifications,
24
as well as PowerPC. As for PowerPC, the specification didn't say whether ppc32
25
or ppc64 or both will be supported.\footnote{This has later proven a bit problematic
26
because it is not very clear what ppc32 should be (i.e. the 32-bit G4 processor is not
27
compatible with the 32-bit mode of the G5 processor.}
28
 
29
It is worth noting that we wanted to be sure of access to respective hardware
30
or at least simulator, prior to committing to support particular architecture.
31
The decision to support almost all suggested architectures\footnote{Namely, we didn't declare
32
support for sparc64, but it got supported anyway as part of \JJ's master thesis.} came after
33
we had known for sure the above condition was satisfied.
34
 
35
We constructed our specification so that it contained a well defined
36
set of mandatory features of the kernel and the userspace layer
37
that had to be implemented. Besides the mandatory features, there
38
was also an optional part comprising of three research or experimental
39
topics. We hoped to eventually find time to work on them.
40
 
42 jermar 41
\section{Project meetings}
36 jermar 42
After adopting our specification, we started to meet regularily every two weeks
43
for the sake of consultations. The regular meetings were cancelled only during
44
the exam periods and summer holiday. The first meeting took place on April 28,
42 jermar 45
April. There had been exactly twenty three project meetings before 1.0.0 release.
36 jermar 46
 
47
The Faculty of Mathematics and Physics officially opened our project on June 10,
42 jermar 48
2005. However, serious collective work on the project, preceeded by individual
49
efforts of some team members, began two months later.
36 jermar 50
 
42 jermar 51
\section{Planning work}
52
In the beginning, we structured our work by creating three two-member teams,
53
each dedicated to one new architecture (i.e. amd64, ia64 and ppc32). However,
54
dividing into couples didn't work out for the amd64 and ppc32 teams. In the end,
55
both of those architectures were supported only with one member of respective
56
team. This might have been because of two factors. First, the collective responsibility
57
for the project allowed the less motivated members to work less than others.
58
Second, over the time, some developers profiled out to be good at specific tasks to which
59
they later adhered and were forwarded more similar work. It was generally accepted
60
within the team if one of the couple traded one architecure-specific task for another task
61
on HelenOS.
62
 
63
\section{Kernel camps}
64
There were two really important moments in our development process. Both of them
65
took place in Harrachov, Czech Republic, where five team members moved two times, each
66
time for a week of full-time intensive HelenOS development. These actions were
67
called Kernel Camp 2005 and Winter Camp 2006. The former camp took place in August 2005
68
and was focused on getting all the architectures into our source tree and deepening
69
their support. The latter camp took place in March 2006 and was dedicated to userspace
70
support. In fact, we made the second camp the deadline for userspace milestone. With the
71
exception of ppc32, all ports had some support for userspace prior to the second camp.
72
Both of the camps moved the project miles ahead.
73
 
74