Frequently Asked Questions

Fundamental Concepts

What is a microkernel?

In a microkernel operating system certain functionality such as device drivers, file systems and networking is moved out from the kernel space to the user space. Code taken out of the kernel runs as a normal user process or processes. The microkernel itself provides only minimal functionality that is necessary for user processes to run and communicate. This strongly contrasts with the traditional monolithic operating systems that keep most of these functions inside the kernel. The main rationale for constructing operating systems along the microkernel design lines has been achieving greater extensibility by forcing most of the operating system policies into the user space parts and leaving the microkernel itself free of policies as much as possible. This makes it possible to use different operating system personalities, potentially even in parallel, on top of the same microkernel and easily change functionality that would have otherwise been hardcoded in the operating system kernel. Note that multiserver microkernels bring the additional benefit of a limited fault-tolerance: a bug in a kernel driver of a monolithic operating system usually results in the crash of the entire system whereas a bug in a user space driver of a microkernel operating system is confined to the user process in which the driver runs.

What is a multiserver?

Within the scope of microkernel operating systems, a multiserver spreads the operating system functionality over multiple user processes. Note how this differs from a single-server microkernel that concentrates all these functions into a single user process. The motivation for structuring the system as a multiserver is the elimination of the single point of failure represented by the single server process in a single-server system. Another advantage of a multiserver system is smaller and simpler components that can communicate only via explicit interfaces. Smaller and simpler components benefit from the separation of concerns, can do one thing really well and are easier to reason about. Explicit interfaces make the components interchangeable and the correctness of the system on the component-granularity level is easier to reason about. At the same time, it is more difficult to use the component in a wrong way.

General HelenOS Questions

What is HelenOS?

HelenOS is an open-source microkernel-based multiserver operating system written from scratch. It runs on several different CPU architectures (IA-32, x86-64, SPARC V9, IA-64, PowerPC, ARM, MIPS). HelenOS prides in portability, modularity, clean design and coding style.

What is HelenOS used for?

Some people fiddle with HelenOS simply as a hobby, some people use it as a device for achieving their professional goals (i.e. in operating systems research). HelenOS is also used as a platform for school assignments for the ​Operating Systems course at the ​Faculty of Mathematics and Physics, Charles University, Prague, as well as for the students' bachelor theses, master theses and team software projects.

At this point we don't consider HelenOS usable for something different than development and research, but we're getting very close to the point where it will be usable for something really practical.

What license is HelenOS released under?

All original HelenOS code is covered by a BSD-like license. Some specific third-party components are covered by the GPLv2. See this page for more details.

Is it based on Linux? Is it UNIX-like?

No. HelenOS is based on original code, from the ground up. It is based on the original SPARTAN microkernel. It does not mimic any existing system and it is not meant to be POSIX-compliant or UNIX-like at all. Just as an example, HelenOS does not support fork().

What does it do, from an end-user's perspective?

We have a command line and a simple graphical user interface which allow you to manipulate files, run applications and mount file systems from disks and disk images. You can play Tetris or edit text files. HelenOS supports multi-national text throughout thanks to using UCS (i.e. Unicode). We also have networking so you can run a simple web server on HelenOS or control HelenOS remotely over the network. HelenOS can play some music for you, too. We have ported some third-party development tools, among which are GCC, binutils, Python and pcc.

What do you aim for with HelenOS?

Mainly three things. One is to create a fully usable operating system (i.e. a system that could be used for at least some everyday tasks, for example to act as a router, a server, a PDA or a desktop), The second goal is to be able to experiment with new ideas and approaches in operating system design and implementation on a system that is designed for practical usability. Last, but not least, the goal of developing HelenOS is to have fun.

How is HelenOS development organized?

HelenOS development is community-driven, with a core team of long-time developers and a loose group of contributors. The primary communication medium for all developers and contributors is our ​development mailing list. Since most long-time developers are currently based in Prague (or vicinity), we hold developer meetings in Prague once every month. Minutes are usually published on the mailing list. The decision processes in the HelenOS community could be described as open and consensus-seeking, but meritocratic. A working piece of code weights more than thousand words, but the code must be well-intented, well-designed, well-implemented and well-documented.

Where is HelenOS source code kept?

HelenOS source code is currently managed with ​Bazaar DVCS. Bazaar is distributed and similar in operation to Git or Mercurial. We have a central repository which is considered as the most current official code base. Several developers also have their private development branches which are publicly viewable (usually on ​launchpad). A switch from Bazaar to Git is planned for the near future.

I would like to contribute to HelenOS. Where should I start?

We have several pages on our wiki that should help and guide any prospective contributors. Please read carefully our general summary for contributors and our tips for (not only) students (the tips really do not target only students) and the links on these pages. A natural first prerequisite for any contribution is that you are able to compile HelenOS from sources and run it. But note that compiling HelenOS from sources is not necessary for just casually giving it a try (you can easily run a pre-built, supported HelenOS image).

If you want to contribute by reporting a bug to us, please read our instructions on how to file a bug. Also please consider finishing this FAQ, because it might explain the big picture of HelenOS.

Comparison with other systems

How is HelenOS different from UNIX?

See our page which describes some design differences between HelenOS and UNIX-like systems.

How is HelenOS different from GNU Hurd?

​GNU Hurd reimplements UNIX in a multiserver environment on top of the Mach microkernel. As of version 0.7, the Hurd runs on single-processor ia32 systems. Porting effort to amd64 is underway. Some of the Hurd's components, such as parts of the ext2fs file server and the pfinet networking server are in fact scavenged from ancient versions of Linux, while some other components are original. The networking stack has a single-process architecture. NIC and disk drivers are also taken from Linux, but run as part of Mach in kernel mode. There are experimental versions of the Hurd with support for running Linux 2.6.x networking and disk drivers in user mode via the DDE compatibility layer. The Hurd's hardware support is rather limited. As of version 0.7, it did not support USB or sound. There are, however, experimental PoC's implementing USB and sound via rump kernels. The Hurd is a multiuser system and a huge emphasis is put on structuring it in such a way that unprivileged users can work with the computer without needing to acquire the administrator's privileges for certain tasks (e.g. making untrusted/experimental file systems accessible in the file system namespace). The Hurd offers great flexibility in the dynamic configuration of the system through the translator mechanism. Users can modify behavior for a file system path by interposing their own functionality (i.e. setting a translator) that gets activated on open. There are two GNU Hurd distributions: Debian GNU/Hurd and Arch Hurd. The former includes about 80% of the Debian packages, which is still in the very much respectable order of tens of thousands of packages.

HelenOS, on the other hand, is a multiserver environment which does not reimplement any legacy system. It has its own microkernel called SPARTAN. Besides ia32, it also supports amd64, arm32, ia64, mips32, ppc32 and sparc64 to varying degrees, some of them in multiprocessor configurations. An overwhelming majority of HelenOS components such as file systems, networking stack, device drivers and GUI have been written specifically for HelenOS, so there is virtually no bloat introduced by various compatibility layers and glue code, neither there is any additional maintenance burden associated with maintaining aging third-party components. The networking stack is decomposed into several processes, each implementing part of the stack such as IP, TCP or UDP. Essentially all HelenOS drivers run in user mode, the exception being kernel drivers used for debugging purposes and the timer and interrupt controller drivers. HelenOS supports both USB and sound (Sound Blaster 16 and Intel HDA). HelenOS is a single user operating system, even though there has been some experimental work done on multiuser support. The closest analogy to the translator mechanism is exposing services in the location service filesystem. The system configuration can be dynamically changed by spawning/killing user space servers that implement certain IPC protocols and by stacking services on top of each other. HelenOS currently does not support very many user applications as the development focus is on subsystems, frameworks and drivers. A very limited support exists for running a few standard development tools inside HelenOS (e.g. binutils, gcc, python and some others). See also the following question.

How is HelenOS different from MINIX 3?

​MINIX 3 is a multiserver system which comes with its own microkernel and core services, and portions of NetBSD userland. The microkernel does not support threads. As of version 3.3.0, MINIX runs on single-processor ia32 and arm32 systems. Some multiprocessor code is present, but has been unmaintained since version 3.1.x. MINIX 3 comes with two alternative networking stacks. Its own inet server and the lwip server based on the lwIP networking stack. Even though lwIP contains some experimental support for IPv6, both servers are IPv4 only. IPv6 support for the lwip server is work in progress. Both inet and lwip have monolithic architecture that combines IP, UDP and TCP in one process. Some research has been done on making the networking stack modular. The file systems and most of the device drivers have been developed specifically for MINIX. As of version 3.3.0, MINIX supports USB hubs, USB mass storage and the MUSB OTG controller (as found on some SoCs). The standard USB host controllers or the USB human interface devices are not supported. There are development versions of MINIX 3 that use Linux 2.6.29 USB drivers running inside the DDE compatibility layer. The selling point of MINIX 3 has been its reliability features. MINIX 3 contains a resurrection service that can, in some situations, restart a crashing or misbehaving service. The development version of MINIX 3 supports live update of the running system services. Thanks to its NetBSD userland, MINIX 3 boasts thousands of packages.

To avoid much repetition, see also the answer to the previous question. On top of that, the HelenOS kernel implements kernel threads. HelenOS modular networking stack supports both IPv4 and IPv6. The HelenOS USB stack supports UHCI, OHCI and EHCI. Drivers for USB hubs, human interface devices (a.k.a. mice and keyboards) and mass storage are available. HelenOS does not come with a resurrection service nor live update.

How is HelenOS different from Genode?

​Genode is an operating system component framework which makes it easy to reuse diverse third-party components (alongside original Genode components) in a multiserver environment. It supports the combination of several different microkernels (and even monolithic kernels such as Linux) with various original and wrapped user space components (e.g. foreign device drivers wrapped by a DDE layer or a rump kernel). The granularity of the user space components is varying, from fine-grained to large and monolithic. Of course, not all theoretical combinations of components work in Genode and also the feature set can differ. Genode uses a recursive system structure in which components are organized in a tree hierarchy. A parent component has full control over its children and, at the same time, gives its children a portion of its own resources such as RAM to start with. Genode components, and especially the root core component, enforce efficient resource accounting by requiring payments (in terms of resources) for services they provide. Genode components can use a special resource trading protocol to adjust their resource consumption dynamically.

Compared to this, HelenOS is a coherent combination of a single portable microkernel and a multiplatform userland designed and built natively for it from fine-grained components. We strongly prefer designing and implementing our own components to importing foreign components from other systems and wrapping them into bloated compatibility layers, especially when dealing with the critical core components of the operating system. HelenOS supports basic resource accounting, but currently not so elaborate as in the case of Genode. Unlike Genode components, HelenOS components are not organized in a strict hierarchy and the whole system structure is rather flat.

How is HelenOS different from L4Re?

​L4Re is a multiserver operating system built on top of the Fiasco.OC microkernel. As of release r72, it runs on amd64, arm32, ia32, mips32 and mips64 processor architectures, supports SMP and specializes in virtualization. Above the microkernel runs a set of userspace components that fall into several categories: native L4Re components (such as the root and init tasks, I/O manager, drivers and virtual machine monitors), or paravirtualized VMs (L4Linux), or fully-virtualized VMs, or third-party components serving demonstration purposes. The runtime scenarios are mostly statically setup by the init task and the I/O manager according to a pair of Lua scripts. L4Re provides a POSIX interface which allows it to use quite a few contributed packages. L4Re also uses a mixture of native and third party device driver and server components. Notably, the latter has been enabled by the DDE framework which imports portions of Linux 2.6.29, allowing the reuse of compatible Linux device drivers. Alternatively, L4Re can use L4Linux as a driver OS. The released version contains traces of a networking server that combines Linux NIC drivers, DDE and the lwIP networking stack. This component has been however disabled and marked broken as of release r72.

In comparison, HelenOS supports a slightly different set of processor architectures and despite some experimental master theses' results does not currently engage in virtualization. Instead it aims to provide a coherent, dynamic, single-user system composed of many fine-grained components. HelenOS almost exclusively rolls its own original drivers, frameworks, GUIs, networking and filesystems.

Advocacy-related Questions

Oh, yet another operating system?

No, not at all. There are definitely many more various content management systems, office suites or web browsers out there than there are microkernel-based multiserver operating systems like HelenOS.

Toolchain-related Questions

Why don't you use Clang as your primary compiler?

We actually do support Clang as an alternative compiler for some architectures (such as ia32 and amd64). But Clang does not currently support all CPU architectures that HelenOS supports, so we use GCC to build HelenOS by default.