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 |