Subversion Repositories HelenOS-doc

\chapter{Project}

\chapter{Project}

\label{project}

\label{project}

The HelenOS project was formed in late October 2004, when the six

The HelenOS project was formed in late October 2004, when the six

developers grouped and decided to adopt previous work of {\JJ} on the

developers grouped and decided to adopt previous work of {\JJ} on the

SPARTAN kernel\footnote{The SPARTAN kernel has been developed by {\JJ}

SPARTAN kernel\footnote{The SPARTAN kernel has been developed by {\JJ}

since 2001.} as a foundation for their new operating system.

since 2001.} as a foundation for their new operating system.

\section{Specification}

\section{Specification}

The team had then worked on a specification\cite{helenos-spec} until

The team had then worked on a specification\cite{helenos-spec} until

March 8, 2005. The specification was based on \MD's draft and

March 8, 2005. The specification was based on \MD's draft and

incorporated many suggestions from other members of the team. The

incorporated many suggestions from other members of the team. The

biggest part of the discussion was concerned about how many and what

biggest part of the discussion was concerned about how many and what

processor architectures we will support. At that time, the SPARTAN

processor architectures we will support. At that time, the SPARTAN

kernel supported ia32 and mips32 to the extent that kernel threads could

kernel supported ia32 and mips32 to the extent that kernel threads could

be scheduled. The ia32 port could do some very basic virtual memory

be scheduled. The ia32 port could do some very basic virtual memory

operations and was capable of SMP service. Moreover, the mips32 port ran

operations and was capable of SMP service. Moreover, the mips32 port ran

only in the msim simulator. None of them supported userspace threads.

only in the msim simulator. None of them supported userspace threads.

We realized the need to support at least one 64-bit architecture and

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

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,

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,

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

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

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

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

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

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.

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

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

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 had known for sure the above condition was satisfied.

We constructed our specification so that it contained a well defined

We constructed our specification so that it contained a well defined

set of mandatory features of the kernel and the userspace layer

set of mandatory features of the kernel and the userspace layer

that had to be implemented. Besides the mandatory features, there

that had to be implemented. Besides the mandatory features, there

was also an optional part comprising of three research or experimental

was also an optional part comprising of three research or experimental

topics. We hoped to eventually find time to work on them.

topics. We hoped to eventually find time to work on them.

\section{Project meetings}

\section{Project meetings}

After adopting our specification, we started to meet regularily every two weeks

After adopting our specification, we started to meet regularily every two weeks

for the sake of consultations. The regular meetings were cancelled only during

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,

the exam periods and summer holiday. The first meeting took place on April 28,

The Faculty of Mathematics and Physics officially opened our project on June 10,

The Faculty of Mathematics and Physics officially opened our project on June 10,

2005. However, serious collective work on the project, preceeded by individual

2005. However, serious collective work on the project, preceeded by individual

efforts of some team members, began two months later.

efforts of some team members, began two months later.

\section{Planning work}

\section{Planning work}

In the beginning, we structured our work by creating three two-member teams,

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,

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,

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

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

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.

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

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

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

within the team if one of the couple traded one architecure-specific task for another task

on HelenOS.

on HelenOS.

\section{Kernel camps}

\section{Kernel camps}

There were two really important moments in our development process. Both of them

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

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

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

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

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

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

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.

exception of ppc32, all ports had some support for userspace prior to the second camp.

Both of the camps moved the project miles ahead.

Both of the camps moved the project miles ahead.

\section{Coding style}

\section{Coding style}

We have adopted common coding style specification in order to improve code readibility and

We have adopted common coding style specification in order to improve code readibility and

maintainability. Even though the specification relates only to stylistic matters,

maintainability. Even though the specification relates only to stylistic matters,

following it has the potential to encourage and improve cooperation within the team and

following it has the potential to encourage and improve cooperation within the team and

provide good preconditions for future project growth.

provide good preconditions for future project growth.