The HelenOS project was formed in late October 2004, when the six
developers grouped and decided to adopt previous work of {\JJ} on the
SPARTAN kernel\footnote{The SPARTAN kernel has been developed by {\JJ} since 2001.} as a foundation for their new operating system.
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
biggest part of the discussion was concerned about how many and what
processor architectures we will support. At that time, the SPARTAN
kernel supported ia32 and mips32 to the extent that kernel threads could
be scheduled. The ia32 port could do some very basic virtual memory
operations and was capable of SMP service. Moreover, the mips32 port ran
only in the msim simulator. None of them supported userspace threads.
We realized the need to support at least one 64-bit architecture and
have long discussed whether it should be amd64 or ia64. We also considered
ppc64. At the end, we decided to declare support for three new architectures,
five architectures in total. Both amd64 and ia64 made it to the specifications,
as well as PowerPC. As for PowerPC, the specification didn't say whether ppc32
or ppc64 or both will be supported.\footnote{This has later proven a bit problematic because it is not very clear what ppc32 should be (i.e. the 32-bit G4 processor is not
compatible with the 32-bit mode of the G5 processor.}
It is worth noting that we wanted to be sure of access to respective hardware
or at least simulator, prior to committing to support particular architecture.
The decision to support almost all suggested architectures\footnote{Namely, we didn't declare support for sparc64, but it got supported anyway as part of \JJ's master thesis.} came after
we had known for sure the above condition was satisfied.
We constructed our specification so that it contained a well defined
set of mandatory features of the kernel and the userspace layer
that had to be implemented. Besides the mandatory features, there
was also an optional part comprising of three research or experimental
topics. We hoped to eventually find time to work on them.
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,
2005. There were exactly twenty two project meetings before 0.2.0 release.
The Faculty of Mathematics and Physics officially opened our project on June 10,
2005. However, serious collective work on the project, preceeded by individual
efforts of some team members, began two months later.
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.
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.
We have adopted common coding style specification in order to improve code readibility and
maintainability. Even though the specification relates only to stylistic matters,
following it has the potential to encourage and improve cooperation within the team and
provide good preconditions for future project growth.