Subversion Repositories HelenOS-doc

Rev

Rev 42 | Go to most recent revision | Blame | Compare with Previous | Last modification | View Log | Download | RSS feed

  1. \chapter{Project}
  2. \label{project}
  3.  
  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.
  8.  
  9. \section{Specification}
  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.
  19.  
  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.  
  41. \section{Project meetings}
  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,
  45. April. There had been exactly twenty three project meetings before 1.0.0 release.
  46.  
  47. The Faculty of Mathematics and Physics officially opened our project on June 10,
  48. 2005. However, serious collective work on the project, preceeded by individual
  49. efforts of some team members, began two months later.
  50.  
  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. \section{Coding style}
  75. We have adopted common coding style specification in order to improve code readibility and
  76. maintainability. Even though the specification relates only to stylistic matters,
  77. following it has the potential to encourage and improve cooperation within the team and
  78. provide good preconditions for future project growth.
  79.