Subversion Repositories HelenOS-doc

Compare Revisions

Ignore whitespace Rev 35 → Rev 36

/prjdoc/trunk/tools/tools.tex
129,6 → 129,12
GNU C library for some time. However, the version we are using is not optimized for SMP and multithreading.
We plan to eventually replace it with another allocator.
 
Finally, the {\tt pci} userspace task is using the {\tt libpci} library. The
library was simplified and ported to HelenOS. Even though filesystem
calls were removed from the library, it still heavily depends on {\tt libc}.
By porting {\tt libpci} to HelenOS, we demonstrated that applications and libraries
are, given enough effort, portable to HelenOS.
 
\section{Build tools}
Assembler, linker and compiler are by all means the very focal point of attention
of all operating system projects. Quality of these tools influences
/prjdoc/trunk/project/project.tex
1,17 → 1,47
\chapter{Project}
\label{project}
 
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 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. 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 and five architectures in total, including
both amd64 and ia64 and also ppc32.
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,
April. There had been twenty project meetings before 1.0.0 release.
 
The Faculty of Mathematics and Physics officially opened our project on June 10,
2005.