The ability to execute Qt-based applications natively on a range of different kernels is one of the most visible features that attracts users to the framework. Even though Genode's developers closely follow the development of Qt5 and greatly appreciate the direction Qt is heading to, however, the latest Qt version supported by Genode used to be 4.8.4. With the new release, Genode finally made the switch to Qt version 5.1. The porting of Qt5 was not an easy walk because the platform interfaces of Qt underwent significant changes between versions. In particular, the Qt Window System (QWS), on which Genode formerly relied, got replaced by the new Qt Platform Abstraction (QPA) interface. This created a gap between the functional requirements of QPA and Genode's GUI server called nitpicker. This gap was bridged quite cleverly by using Genode's component composition techniques. An outline of the idea and the resulting solution can be found in the release documentation.
The second focus of the current release was the addition of multi-processor support, in particular when using the NOVA microhypervisor as kernel. This topic has been discussed for multiple years by now. The basic problem can be stated as follows. Genode relies on synchronous inter-process communication for letting components interact with each other and for delegating access rights. NOVA provides such an IPC mechanism, but it only works if both communication partners reside on the same CPU. Communication between CPUs is solely possible via shared memory and semaphores. The restriction is not arbitrary. The NOVA developers have good reasons for choosing their design, scalability and IPC performance being the most prominent ones. As a consequence, programs running on top of NOVA need to be aware of the assignment of threads to physical CPUs to comply with this restriction. On the other hand, the Genode API does not impose such a restriction to the application programmer. The API allows for the creation of threads and threads are expected to communicate with each other over synchronous IPC. The circumstances of which thread happens to be executed on which CPU don't matter and should not matter at Genode's API level. After a years long discussion of both schools of thought, a series of experiments was kicked off, which ultimately yielded a surprisingly simple design. As a result, Genode has become able to leverage multiple CPUs on NOVA in a way that preserves both NOVA's incentives, and Genode's existing API.
Regardless of the particular kernel Genode is used with, one problem is shared by all users of Genode: Complex system scenarios with many components are hard to analyze, which makes it extremely challenging to identify the cause for performance problems. Hence, the process of optimizing application performance, more often than not, tends to be a series of hit-and-miss experiments. To pinpoint performance bottlenecks easier, the framework has gained a new tracing facility that is deeply built-in and always enabled. The tracing support allows for the monitoring of inter-component communication whereas the policy of which information to capture can be defined at runtime, similar to dtrace. The design is the result of more than one year of exploration and experimental work with the goal to facilitate Genode's architecture for approaching the problem rather than porting an existing solution. The effort paid off. Compared to existing tracing toolkits, which were designed with monolithic OS kernels in mind, Genode's tracing facility is strikingly simple yet powerful.
Further improvements of the new version are added device drivers for the Exynos-5 SoC, updated kernels, improved virtualization support for x86 on NOVA, and new integrity checks for 3rd-party source codes ported to Genode.
All those topics are covered along with lots of background information in the release documentation of version 13.08.