Version 62 (modified by Jakub Jermář, 6 years ago) ( diff )

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.

Are microkernel-based systems inherently slow?

No, but there is an inherent performance penalty stemming from the higher number of context and address-space switches of the microkernel-based systems as compared to the monolithic operating systems. Literature however tells us that this penalty can be as low as around 6%, if the system is implemented with due care. The penalty should be viewed as a price of the benefits we get with these systems. It's analogous to sacrificing a little bit of performance for the comforts of using high-level programming languages.

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.

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 Git. Developers are encouraged to host their development branches on GitHub by cloning repositories at

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 the behavior of the system by associating an IPC server with an arbitrary file system node (i.e. setting a translator) that gets called when the file system node is visited. 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, EHCI and XHCI. 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 framework built on top of the Fiasco.OC microkernel. The kernel is capability-based and has real-time features. As of release r75 from October 2017, L4Re runs on amd64, arm32, arm64, 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, GUI window manager and virtual machine monitors), or paravirtualized VMs (L4Linux), or fully-virtualized VMs, or third-party components serving demonstration purposes. The runtime scenarios are mostly (but not exclusively) 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 was historically enabled by the DDE framework which imported portions of Linux 2.6.29, allowing the reuse of compatible Linux device drivers. More recently, L4Re has used L4Linux and even fully-virtualized VMs as device driver OSes. L4Linux can be used also as a server component. The previously 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. Its kernel does not provide real-time guarantees. HelenOS' connection-oriented IPC is essentially a coarse-grained capability system for a single type of kernel objects: asynchronous IPC endpoints, known as answerboxes in HelenOS. HelenOS aims to provide a coherent, dynamic, single-user and generic-purpose system composed of many fine-grained components. HelenOS almost exclusively rolls its own original drivers, frameworks, GUI, networking and filesystems.

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.

Note: See TracWiki for help on using the wiki.