Posted on | August 20, 2008 | 1 Comment
Recently, I had the opportunity to interview Jakub Jermar via e-mail regarding his motivation behind creating and advancing HelenOS, an operating system based on the from-scratch Spartan microkernel. An important disclaimer, I am a contributor to HelenOS for my own reasons. My status as a contributor did not stop me from challenging Jakub with interesting questions.
Microkernels are most decidedly not dead, the amount of people working on things like Minix, L4 and (yes, even to this date) Mach represent a considerable interest in an “old but new” kernel design.
Who is Jakub, what is HelenOS, why make HelenOS? Read on
This is not a resurrection of the Torvalds/Tanenbaum debate although that debate was quite funny if you remember it. We’ve grown past most of those arguments. In the future, I’ll challenge Jakub and others to another interview and really get in to the nuts and bolts. For now, enjoy.
 Who is Jakub, where do you work, what do you do?
I am a 27 year old Czech who enjoys system programming. At the moment, I work for Sun Microsystems. I fix bugs in Solaris kernels and the related low-level libraries. Besides operating systems, I also like compilers, but unfortunately I don't have much free time for doing serious compiler work. I am married but still have no children. When I am not spending the rest of my free time with my wife, I can be found working on HelenOS.
 You set out to develop a modern operating system, why write you own kernel and more specifically, why a microkernel?
Everyone must admit that writing one's own kernel is cool. I became obsessed by this idea when I read The Design of the UNIX operating system by M. J. Bach ten years ago. In that book he describes the origins of UNIX. I liked the introductory part which tells the story about how Ken Thompson wrote a kernel from scratch. Several years later, when I was at the university, I was given about a dozen programming assignments from different software engineering subjects. My work on them gradually evolved into what is today known as HelenOS. It must be noted, however, that I was later joined by more people from the university who considerably improved the project and some of them are still around and active.
As for the microkernel part of the question, the answer is that from the software project planning point of view, it seemed easier to create a microkernel. We set the microkernel course right at the beginning because we knew that our time for the university project is limited. With a microkernel you can say that the project is done even when you have very few drivers and the system lacks features like file system and networking.
Nevertheless, the thing is that for some time of the initial development of an operating system, you can't really tell whether it is going to be a microkernel or a monolithic kernel. And indeed, by the time we had a functional support for virtual memory and even for running userspace threads, it could have gone in both directions. There were also other factors which contributed to our choice to create a microkernel. As far as memory serves, these were the desire not to clone Unix and to come up with something small, which can be wholly understood by its authors.
 Many microkernel based operating systems are in development, why not just hack one of those and send patches?
Back at the university, they told us: "microkernels are dead, operating system research is dead". Then 2001 came and I started to work on HelenOS. Even when the other guys joined me in 2004/2005, there was still no sign of the third incarnation of Minix. We found out about L4 by the time we were designing our own IPC (and for some reason implemented it completely the other way around). So the only one who was really dead was Mach, but we didn't know it and even if we did, it would probably not prevented us from working on our own project.
When I look at the different microkernel based operating systems today and compare their features with HelenOS, I see two things. The first is that HelenOS is still incomplete when it comes to features like networking and available applications. On the other hand, HelenOS is probably the most portable one and supports the most processor architectures. It supports virtual memory and also multiprocessor systems, which is kind of an unfulfilled dream for many.
So for us, it doesn't make much sense to send patches to another microkernel projects because we are busy enough testing and improving our own baby. For other people, it depends on whether they see themselves rather as users or rather as developers. If the former is the case, it makes certainly better sense to send patches to other projects now, because you still cannot browse the web with HelenOS and you can't play music from HelenOS. On the other hand, developers could appreciate the project because it still offers space for creativity and gives them, in my opinion, a better kernel.
 Is HelenOS also a teaching OS? Can educators who see value in your design join in? Students of the Operating Systems course at the Charles University have used HelenOS to complete alternative semestral assignments. The arm32 port is an example of such an effort.
Other groups of students were improving the kernel timeout subsystem and there are several master theses in progress. Most of them are trying to deliver the missing features.
According to ohloh.net, HelenOS has extremely-well commented sources, which certainly doesn't hurt when you want to understand an operating system's principle. We try to publish documentation and defended theses and papers on our web, which complements the source code.
 World politics and political barriers seem to be in an ever changing state. How do you see this effecting HelenOS?
As long as the HelenOS developers are free to work on HelenOS and as long as HelenOS is available to people as free software, it is not affected. Anyway, software is software and politics is politics, isn't it?  HelenOS is mostly released under the modified BSD license, are you worried about the "one way" effect?
If someone takes HelenOS, removes the tiny GPL bits and continues to work on it behind closed doors, we can't really blame them. The BSD license allows something like that and we made it possible by choosing the license. On the other hand, both parties benefit if the development continues in the open.
 HelenOS aims to be a modern, fully functional operating system. How long until it takes the leap from being developed on simulators to actually becoming usable as a stand-alone OS on bare metal?
Well, you can boot it and use it on bare metal even now. Currently the system will boot off a file system on a ramdisk and you won't be able to do much more than spawn yet another tetris task. But the answer to your question depends on what you intend to do with it.
In order to become more usable, we need at least an IDE block device driver, entire networking support and applications like vim and gcc. That could take us another year or two.
 Is HelenOS receptive to newcomers? Are you adopting the tight knit approach that made Linux a success or doing something different?
Oh yes, newcomers are welcomed in our project and, in fact, they are absolutely necessary. Of the original six authors, only weak half are actually active and productive. Fortunately we were able to attract some new people who make some of the best contributions. In the past, new people were recruited exclusively from Charles University, but recently we have been hit by a wave of interest from abroad.
As for the tight-knit approach, the development team is so small now that everyone has a commit access and can basically do whatever they like. In reality, big changes are carried out only by few people so not everyone is equally active. In this regard, the development team organizes itself and the network of trust among developers evolves autonomously, based on each one's contributions.
 How closely will HelenOS follow traditional POSIX standards, or does POSIX not apply to HelenOS?
Internally, HelenOS is not a POSIX-like operating system and being POSIX-compliant was never our goal. On the other hand, our file system layer implements a subset of POSIX file system interfaces and deviates from the standard only a little. We made this design decision in order to make porting a little bit easier.  If someone wants to start hacking away at HelenOS, where should they begin?
First of all, they should subscribe to our mailing list and track our source code repository. They should install the necessary toolchain and try to build HelenOS. After that, booting HelenOS, possibly in a simulator, is a must. After playing tetris for some time and experimenting with kconsole and the rest of the system, they might get some basic taste for what they'd like to do with HelenOS.
Alternatively, people can pick up a bug from our bug database and try to fix it. And who knows, after two non-trivial patches, we might offer them commit access...
Thanks, Jakub for the interview and information. If you want to dig in to HelenOS or just try it out, you can find it here. Comments are welcome.
A note on copyright:
Echoreply traditionally reserves all rights under copyright law, however permission is granted to share the text of this post (verbatim) or this entire document verbatim, without royalty through any medium provided that the following copyright notice is preserved:
Copyright (C) 2008 Jakub Jermar, Copyright (C) 2008 Tim Post.
Permission to translate and copy this document (thereby modifying the document) is granted, provided that all copyright notices and this sentence remain intact.
All other rights remain reserved.