Guest post by With the release of version 14.02, the Genode project has added two major features to the OS-construction framework: Using VirtualBox on top of Genode/NOVA, a wide range of unmodified guest OSes can now be integrated as components into Genode-based systems. The second feature is the addition of the file systems of the NetBSD kernel as rump kernels. The release documentation covers plenty of further improvements.
With storage and virtualization, the new release addresses two topics that are fundamental for using Genode as general-purpose OS, and both topics have been approached in a pretty holistic manner.
When it comes to storage, the project has significantly advanced over the past year but a few key pieces were still missing, namely mature file systems and a block cache. After having investigated FUSE-based file systems in the previous release, the project started exploring so-called rump kernels, which enable the execution of subsystems of the NetBSD kernel at user level. Originally, the rump kernel project was created to ease the development of drivers on NetBSD. The basic idea behind them is to link a driver to a stripped-down version of the NetBSD kernel that does not contain any privileged instruction. Hence, it can be executed in user mode. To interact with the outside world, a rump kernel uses a small so-called “hypercall” interface. By implementing this interface on top of the Genode API, rump kernels have become usable on Genode now. The immediate benefit is the availability of the time-tested file systems of the NetBSD kernel. But in the future, other NetBSD subsystem such as the TCP/IP stack or device drivers could be considered just as well.
At block level, the project took the chance to redesign the internal interfaces of the existing block-level components to support fully asynchronous operation. This step enables the effective use of modern disk-controller features such as native command queuing, and even the out-of-order processing of block requests. As the cherry on top of this line of work, there is a new block-cache component.
Over the past 5 years, virtualization has always played a role for the project. It started with running the paravirtualized OKLinux on top of the OKL4 microkernel. Later L4Linux was made available to Genode running on the Fiasco.OC kernel. Once the NOVA hypervisor found its way to the framework, the project embraced the use of the Vancouver virtual machine monitor, which enabled the use of unmodified Linux kernels. However, none of these solutions appealed well for a large user base, mainly because they were difficult to use or lacked features. By adding support for VirtualBox on top of NOVA, the project has finally found an answer to the question for product-grade virtualization on top of the framework. The integration of VirtualBox with Genode was no ordinary porting work but quite an engineering feat, which turns the architecture of VirtualBox pretty much upside down. In contrast to the host operating systems already supported by VirtualBox, Genode’s version does not extend the host kernel in any way. VirtualBox leverages hardware-based virtualization (VT-x) but lives as a plain user-level program with no special privileges.
As with each new version, there are numerous smaller improvements and new features. For example, a new pseudo file system called trace-fs makes it possible to interactively use Genode’s event tracing mechanism via Unix tools such as cat, grep, and echo.
All the changes are covered in detail in the release documentation of version 14.02.
Really nice seeing the progress on Genode.
Supposing someone, let’s say a friend of mine, had been reading about Genode for a few years now. And let’s say this friend of mine was interested in giving it a spin. What would you suggest as a good use case for a test drive? Run it on bare metal or in a VM? Is there any work load in particular that really shows off some of the new capabilities available in Genode? Strictly for my friend, you see.
I always run hobby OSes in a VM first. Unless the OS developer has builds or documentation for a specific VM app, I generally start with VMWare and VirtualBox. If it doesn’t run well in either of those I’ll try out some smaller, older projects like Bochs or Qemu. I also have an old PIII class computer with a spare drive that I use for bare metal testing, once I’ve successfully booted and ran the OS in a VM.
Haiku is the only hobby-class OS I’ve been brave enough to run on my main workstation, and that was after unplugging my main OS and storage drives. While I pretty much know what I’m doing, there’s always room for error.
Typically, I dust off an old machine I’ve got kicking around the office and go to town. This has helped scratch the itch for everything from Syllable to Haiku, to ReactOS and MenuetOS (and on and on). For Genode, that doesn’t seem like it’d be sufficient.
Between the capability frameworks and pluggable kernels, I feel like it would need a project or task of some kind above and beyond simply installing it to really get a feel for what they’re doing and what they’re trying to do. Same with something like SmartOS or DragonflyBSD. Yes, you could go the VM route to get a taste, but in order to get a real sense of where the developers are taking the project, I feel like you need to test it in an environment that shows off the project’s strengths.
My friend would, I mean. Darn it.
You are not alone with your request for live system that would make the project easier to explore. There is an ongoing discussion on the project’s mailing list [1] and the issue tracker [2] about it.
[1] http://sourceforge.net/p/genode/mailman/message/32038491/
[2] https://github.com/genodelabs/genode/issues/1000
I wasn’t even aware NOVA existed. Hope to look in to it more someday.