helenOS/built from scratch:
5.15: summary:
. why is the helenOS crew constructing
yet another microkernel, when okL4 is here?
it's an academic project .
. anyway, we need microkernels,
and good competition is a good thing!
. that may be why Google Summer of Code is
funding some of it -- along with genode .
. see helen's wiki
and design papers .
. exploring blogs associated with helenos:
vhotspur:
. get it from helenos-usb.bzr.sourceforge.netvineethpillai:
and compile it with:
make HANDS_OFF=y PROFILE=ia32
It would be better to start with sayingjiri-svoboda/Monday, January 4, 2010 The woes of C:
what HelenOS doesn't offer you.
You would be thoroughly disappointed
if you start with thinking of helenos as a
replacement to you current OS.
HelenOS is an on-going effort to
implement a clean and neat OS
which is so simple to understand from design to code.
... C considered harmful ... HelenOS is written in C.. they point us at the wiki,
C is a programming language created at the beginning of 1970's.
It's creation is closely tied with the birth of UNIX.
At the time of its creation,
C was a simple and yet extremely powerful .
For quite some time C has been showing its age.
Both the core language and the standard library
are becoming more and more inadequate
for implementation of applications.
Working with C strings has always been an extreme pain,
but with multi-byte encoding (i.e. UCS/Unicode)
it has become a nightmare.
In HelenOS we decided to drop the standard C99 way of
handling multi-byte strings altogether
and implement our own.
Needless to say, it's only a little better,
the language won't allow us more.
I demand automatic memory management!
I demand user-defined operators!
String formatting in C is a chapter on its own.
While this could be re-implemented in the standard library
to be extensible
(i.e. allow the consumer to register a
formatting function for their custom type)
we cannot really do away with the need to
provide the argument's type in the formatting string,
at least not in a sensible way.
I demand virtual methods!
What usually drives me mad is the complexity involved
in using a hash table in HelenOS.
I need to implement several callbacks just to get my
int->pointer map.
I want generics! I demand collections!
There is a plan to implement a gui for HelenOS.
Having to implement it in C is just giving me the Willies.
We would probably end up with some monstrosity
like GTK... or worse.
I demand inheritance!
I demand a language worthy of the 21st century!
which has some historical links of interest:
What was the motivation for HelenOS ?jakubsuniversalblog Friday, July 15, 2011
. we have to figure everything ourselves
and then implement it,
and also because we are actually writing
multi-platform code
(not the case with Hurd or MINIX).
-- It got started as an assignment back in 2001
when I was at the university.
In 2004 five other students joined me to work on it
towards a more complete operating system.
Our project was completed in 2006.
Since then,
some of us continue to work on it as PhD students
(we have some research in the area of
general purpose operating system verification)
and some of us really do it as a hobby.
In the past years we delivered support for file systems
and very recently also for networking.
So the initial motivation was rather
[more of] an exercise than some vision.
At that time, MINIX and Hurd seemed long dead
so we felt like the only ones working on
a multi-server system.
Unfortunately we were wrong.
In the more recent years,
we realized that our design allows us to write
small software components
(e.g. file_bd or the partition block device drivers)
and easily combine these components in runtime
according to the requested configuration.
This is similar to designing software by
drawing pictures of interconnected components;
we call it "a box principle".
Of course, the box principle is enabled by the fact that
all the "boxes" communicate using some fixed IPC protocol.
Two boxes are happy to communicate with each other
as long as the protocol is obeyed,
using thus something like box polymorphism,
if I may use a POP term.
Losers assemble, real men compose:
There are basically two approaches to software development.
Assembling the code by cherry-picking pre-made components
or writing nearly everything from scratch.
As usually, both have their cons and pros.
Assembling is suitable for undermanned,
time-or-otherwise pressed projects
or simply for projects with a rather narrow focus
which is noticeable even on the base functionality level.
By reusing third-party components,
these projects avoid the Not-Invented-Here syndrome,
which may be a good thing because
it makes other people's work worthier
and saves the project's own resources.
On the other hand, it may be a bad thing too
as the extensive use of non-homebrew base components
destroys the identity of the accepting project
and can introduce bloat in the form of
various compatibility and glue layers,
as well as the very much undesired burden of
maintaining a large foreign codebase and its bugs.
For example, it turns out that
our companion multiserver projects,
MINIX 3 and GNU Hurd,
already have or soon will have
some parts assembled from:
old Linux networking stack (GNU Hurd)
old Linux device drivers (GNU Mach)
old Linux file system drivers (GNU Hurd)
L4's DDE framework for using
contemporary Linux drivers
(GNU Hurd and MINIX 3)
lwIP networking stack (MINIX 3)
NetBSD standard C library and base utilities (MINIX 3)
This bears questions like
whether MINIX 3 without its traditional userland
will still continue to be MINIX 3
or rather it becomes a NetBSD distro,
and gives us some idea about
why are some GNU Hurd's and GNU Mach's components
stuck in times of Linux 2.2 or even older.
The other extreme is HelenOS,
also an undermanned multiserver OS project
and one in which I am actually involved.
We tend to be affected by NIH [not invented here]
and often find ourselves to be reinventing the wheel,
but at the end of the day, here we go with
our own implementations of the above components
(networking stack, filesystems,
drivers and device driver framework, and libc).
Sure, they may not be perfect today or tomorrow,
but they are native and unique to HelenOS
and remain under our control and in our custody.
No comments:
Post a Comment