The Genode project has released the version 16.05 of the operating-system framework. The new version comes with a fundamentally reworked component API, basic support for the Rust programming language, new ACPI infrastructure, and upgraded device drivers for Intel wireless, Intel graphics, audio, and USB.
The Genode API and the programming styles for developing components evolved over the years. Being born out of the L4 community, the sole reliance on synchronous inter-component communication was deeply ingrained in the developer’s mindset when the project was started ten years ago. It took the project a few years to overcome this misconception and embrace asynchronous communication primitives. Most modern Genode components use a mix of both synchronous and asynchronous inter-component interactions. At the API level, however, the two forms of communication remained to exist side by side instead of being integrated in one holistic design. With respect to programming styles, the project underwent a similar evolution. Coming from C-programming background, many parts of the original API resembled a C-ish programming style such as the prominent use of pointers, format strings, side effects via global function calls, or integer error codes. Over the years, however, the expressiveness of the C++ language got fully embraced and the programming style evolved towards functional programming.
Today, most modern Genode components are designed as single-threaded state machines, triggered only by signals and RPC requests originating from other components. There are almost no dynamic memory allocations. If so, allocations are not anonymous but accounted to a specific allocator. State is explicitly passed as arguments, not captured in the form of globally accessible objects. Thanks to this style, certain classes of bugs such as race conditions or memory leaks are greatly alleviated by design. Genode 16.05 cultivates the modern style of Genode components in the form of a fundamentally revised API. The new API is less complex, much safer, and easier to reason about. To account for this profound change, the release documentation is accompanied by a new edition of the “Genode Foundations” book (PDF).
The second major focus of the current release is the updated arsenal of device drivers. All drivers ported from Linux were upgraded to the Linux kernel 4.4.3. Specifically, the drivers are the Intel wireless stack, the Intel graphics driver, the USB driver, and the TCP/IP stack. Thereby, Genode users are able to leverage the same drivers as up-to-date Linux distributions but with each driver being encapsulated in a dedicated protection domain. The audio driver, which originates from OpenBSD, received an update to OpenBSD 5.9. The device drivers are complemented with new infrastructure that makes ACPI platform controlling and monitoring features available to Genode users.
Further highlights are the added ability to use the Rust programming language in Genode components and the enhanced support for using the GNU debugger on top of the NOVA microhypervisor. Details about all improvements and API changes are provided by the extensive release documentation of version 16.05.
Congratulating the Genode Community
“It took the project a few years to overcome this misconception and embrace asynchronous communication primitives.”
Inspired on Erlang?
Anyway, efficiency calls for synchrony. Being able to handle both models a plus. Hopeful on the work of a more cleaned and integrated solution.
Genode uses OpenBSD’s Audio Driver?
Does that mean Genode uses sndio? If so, color me impressed!
It looks like they decided not to use sndio, but they did port the kernel drivers and audio(4).
http://genode.org/documentation/release-notes/15.05#Audio_drivers_p…
Here is an except from the documentation for those like me who have trouble understanding what Genode is:
Application-specific trusted computing base: A Genode system is structured as a tree of components where each component (except for the root of the tree) is owned by its parent. The notion of ownership means both responsibility and control. Being responsible for its children, the parent has to explicitly provide the resources needed by its children out of its own resources. It is also responsible to acquaint children with one another and the outside world. In return, the parent retains ultimate control over 12 each of its children. As the owner of a child, it has ultimate power over the child’s environment, the child’s view of the system, and the lifetime of the child. Each child can, in turn, have children, which yields a recursive system structure. … At the root of the tree, there is a low-complexity microkernel that is always part of the TCB. The kernel is solely responsible to provide protection domains, threads of execution, and the controlled communication between protection domains. All other system functions such as device drivers, network stacks, file systems, runtime environments, virtual machines, security functions, and resource multiplexers are realized as components within the tree. The rigid organizational structure enables the system designer to tailor the trusted computing base for each component individually. For example, by hosting a cryptographic function nearby the root of the tree, the function is exposed only to the microkernel but not to complex drivers and protocol stacks that may exist in other branches of the tree.
[TCB = Trusted Computing Base]
Surprised of Rust rising a hand around there 🙂
You Team need a ‘on the cheap’ hardware exemplar to promote experimentation on your OS.