Guest post by The just released version 13.02 of the Genode OS Framework comes with major improvements of the underlying kernels. Using the NOVA kernel, the framework can be used to build custom operating systems for IOMMU-enabled machines while also leveraging hardware virtualization. Using Genode’s custom kernel or the Fiasco.OC kernel, the new version targets ARM Cortex-A15-based systems such as the Exynos 5250 SoC.
With version 13.02, the tool kit for building component-based operating systems has gained intriguing new platform features. Genode’s unique approach is to use different kernels for different purposes, yet it provides a uniform API that works across all those kernels. With the exception of one custom created kernel, Genode used to rely on using existing 3rd-party kernels largely unmodified. However, this approach turned out to be a severe limitation because the goals of Genode are not always perfectly aligned with those of the respective kernel developers. Hence, the release cycle of the current version marks the point where the Genode developers started to get their hands dirty with kernel code. Both the NOVA and Fiasco.OC kernels have been forked in order to incorporate Genode-specific additions and optimizations. This step is by no means meant to diverge the development of those kernels as the Genode developers do not aspire at all to take the lead in developing either of them. However, this step takes the upstream development off the critical path of Genode users when it comes to kernel changes that are not anticipated by the upstream kernel developers.
Feature-wise, the NOVA hypervisor developed at Intel Labs is the most sophisticated Open-Source microkernel today. It runs on the latest x86-based hardware, provides lightning fast virtualization capabilities, and supports IOMMUs. Although Genode supports this kernel since the end of 2011, most of its modern features remained largely unused. This has changed now. Thanks to the work on both the NOVA-specific code of the Genode framework as well as the kernel code, the entire Genode software stack becomes available on NOVA, including the ability to execute the Genode build system on the NOVA kernel. Furthermore, thanks to the support by Intel Labs, NOVAs virtualization capabilities have become available to users of the framework. Using the new version, virtual machines running on NOVA can interact with Genode’s network, block-device, graphics, and input interfaces.
Besides the improved NOVA platform, the second highlight of the new version is the added support for the ARM Cortex-A15-based Exynos 5250 SoC. There are two kernels that can be used for targeting this hardware. First, there is a custom kernel created specifically for Genode, which is called ‘base-hw’. It is not a free-standing kernel but it is tightly integrated with Genode’s base system. The second option is the Fiasco.OC kernel. To enable the framework on the Exynos 5250 SoC using the latter kernel, which does not officially support Cortex-A15 yet, the Genode project added the needed platform support to its fork of the kernel code.
In addition to platform-related improvements, the new version comes with a few noteworthy functional additions. A new file-system notification mechanism, similar to inotify on Linux, clears the way for sophisticated dynamic application scenarios. For use cases where a Genode-based system should respond to unexpectedly crashing processes, a new failure-detection mechanism has been introduced. Using this mechanism, a parent process becomes able to watch its children and respond to unexpected behavior.
These and many more improvements are covered in elaborative detail in the release notes of version 13.02.
This project continues to make leaps forward!
The decision to fork the kernels in order to more fully support Genode’s features seems risky in the long term, but it’s probably the right choice.
Keep up the good work – and the status updates!
Thanks for your nice words.
Forking the kernels is the only choice to go forward. If the project wouldn’t have forked NOVA, Genode was not able to execute complex dynamic application scenarios because the kernel was lacking important functionality in this area. The situation for the Fiasco.OC kernel is similar. The kernel lacks support for Exynos 5. So for using Genode on this kernel on this SoC, there is hardly any alternative to maintaining a fork.
The term “fork” has maybe a negative connotation. But I think this is misconception here. We’d be happy to see our changes being picked up by the upstream kernel developers. For example, with the NOVA developers, we are constantly discussing the issues solved by our modifications. So our experience and proposed solutions contribute to the forthcoming development of the kernel.
Norman,
Since Fiasco.OC has been forked, do you think it would be worthwhile to implement the change suggested here: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2012/005361.html ?
That is getting rid of Sigma0 as done by other L4 or L4-like kernels… Or do you think diverging too much from the upstream kernel is not justifiable right now?
I definitely support going this route. In my perception, sigma0 has no tangible purpose. So I see no point in having it included in the trusted computing base. In contrary, it caused us serious (priority inversion) problems in the past, and right now, we are struggling with caching issues on ARM, which may be partially attributed to sigma0 as well (because sigma0 makes it impossible to fully avoid inconsistencies of cache attributes). In this respect, removing it would be a relief.
Another benefit from getting rid of it (and ‘bootstrap’ when we are at it) would be to dissolve the dependencies of Genode from L4re packages such as l4util and uclibc. This way, both the ‘make prepare’ step and the build step would become much faster. Right now, we need to download and build uclibc just to be able to use the kernel, which is hard to justify.
You are right. I definitely agree with this decision.
There are a few directories under l4/pkg that are checked out during the “make prepare” step. Which other ones are feasible to remove from the trusted computing base.
I figure you would keep l4sys, libvcpu, cxx, bootstrap, ldscripts and maybe the drivers-frst?
I would strive to keep solely pkg/l4sys, which contains the header files that form the syscall bindings of the kernel.
About the ‘low latency output’: I seem to remember similar design in CoreAudio and/or PulseAudio (can’t remember), did you use code from these project or did you invent your own way?
We haven’t used existing code for the new audio interface. Low-level interfaces like this one are tightly coupled to the Genode API. Reusing existing work would have meant to create a glue layer between the existing code (that is typically expecting a POSIX-like environment, using mmap, Unix-domain sockets etc.) and the Genode API. I am afraid that this glue layer alone would have exceeded our custom implementation in terms of code complexity.
That said, nothing is set in stone. If we see, down the road, that adopting an existing solution would have been a better choice, we can still revise our decision. To come to the right judgement, we need to gather experience with the new interface first.
You know, this is OSnews OPERATING SYSTEM. So your posting is dead on. BUT it’s a bit mechanical?
Appreciate the posting anyway. I am reasonably technical but have never heard of Genode. Maybe explain a bit more?
The posting sounded like advertising (not a problem for me). But please explain all the abreviations, what is IOMMU or NOVA?
Sorry for not being a nerd enough.
Like the topic of the article though, let’s get back to less Thom opinions and more general OS news
Edited 2013-02-28 19:45 UTC
All the information about I/O MMUs and Genode’s support for them (including nice figures) is just one click on the link in the article away. So, please have a look into our (quite detailed) release notes also written by Norman.
Genode has been covered on OSnews since 2008:
http://www.osnews.com/search?q=genode
A quick google search will turn up relevant results with much information about the projects.
Also, simply clicking the link in the article will provide you much more information about this particular release.
It is on you to inform yourself on the matter.
http://lmgtfy.com/?q=IOMMU
http://lmgtfy.com/?q=NOVA+microkernel
Regards.
Edited 2013-02-28 21:02 UTC
Wondercool,
“You know, this is OSnews OPERATING SYSTEM. So your posting is dead on. BUT it’s a bit mechanical?”
I don’t actually recall seeing anywhere that the ‘OS’ stands for Operating System. It seems a logical conclusion, but it might also have stood for Open Source, or just a cool sounding domain at the time it was registered. Maybe someone with authority on the subject can divulge the original intention for the domain?
“Like the topic of the article though, let’s get back to less Thom opinions and more general OS news”
I suppose the name could change the perception of this website, but it is Thom’s blog after all. I think the “News” aspect is hard to keep both original and interesting at the same time after so many years of covering it.
Personally I’d love to be a part of an original series covering hundreds of technical topics in depth. We could work on real projects with real milestones even if they’re just for fun. The community could vote on what we’d do next. I’d like to go all out with multimedia video interviews and demos, etc. But personally I could not afford to do it for free. Thom has hinted several times that osnews is a labor of love rather than one of profit.
If the money was there, I’d offer to start it up myself, but let me ask an honest question to everyone: how much would everyone be willing to pay a year to get some original R&D stuff going?
It’s a given that OS in the domain name stands for operating system, not just open source. Thom and others before him have covered every operating system under the sun, including Microsoft’s. MS can hardly be called open source.
Alfman, what are you hinting at? “Money for nothing and your chicks for free?”
djohnston,
“It’s a given that OS in the domain name stands for operating system, not just open source. Thom and others before him have covered every operating system under the sun, including Microsoft’s. MS can hardly be called open source.”
Well yes I know that
but the articles covered here are a superset of operating systems just like they are a superset of open source. I don’t find it obvious what the original intent was, but you are probably right.
“Alfman, what are you hinting at? ‘Money for nothing and your chicks for free?'”
Alot of work goes into doing things like this, it certainly wouldn’t be money for nothing. Maybe I could have done it for free before kids, but not now. Maybe someone is willing to volunteer as an unpaid intern, but the project would really call for engineers with more experience. Ultimately though if no one pays, then the in depth engineering articles that some of us would like to read are not likely to be written.
Edited 2013-02-28 23:28 UTC
OS != FOSS
Kochise
Kochise,
That’s not really helpful, I was more interested in the historical intention for the domain name.
FYI I’m not the only one who recognizes that OS could stand for either:
http://www.abbreviations.com/serp.php?st=OS
The first question & answer in FAQs (at the top of this page) makes it pretty clear it’s “operating systems” …still, some OSS zealots don’t seem to realise that, from time to time.
(and are you sure many people wouldn’t be put off by such series of articles? Look what kinds of topics are most commented ;p )
zima,
“The first question & answer in FAQs (at the top of this page) makes it pretty clear it’s ‘operating systems’ …still, some OSS zealots don’t seem to realise that, from time to time.”
I hadn’t read that actually, but that certainly does imply the ‘operating system’ definition. There wouldn’t have been anything wrong with another meaning IMHO, I was just curious. Well, that closes this off topic diversion, my apologies
I’ve just read the long but interesting release notes for “13.02” . I’m so glad to see steady progress in this project. Congrats for that.
OTOH, to be honest, in each release it feels like you have just solved a show-stopper I didn’t even know was there, so I can’t tell how close you are to releasing a workable operating system for the general public.
Are there any concrete plans for Genode-powered consumer devices, such as phones and tablets? Its capability architecture for real-time resource allocation looks like a killer feature.
Thank you for having taken the time to study the release notes. It is great to know that our work is appreciated.
Regarding your question about creating an OS for the general public, to be honest, this is actually not the goal of the project. (it might become a side effect though) Our driving motivation is to provide a compelling tool box to developers who use Genode to build solutions. Genode’s role is the one of a supplier in a value chain. To give an example, Genode might be beneficial for medical equipment. But only if a medical-devices company decides to go for it, our system will enter this category of products.
Our stated aspiration to turn Genode into a general purpose OS is primarily motivated by our (developers) desire to use the system for our daily computing routine and to give proof of the soundness and fitness of the system. The result is not meant to be offered as a product to end users.
As far as I know, there are no Genode-based consumer devices on the horizon.
I have always been a micro-kernel fan and is very pleasing to see this project going forward.
Congratulation for the good work.