Linked by nfeske on Thu 28th Feb 2013 12:08 UTC
OSNews, Generic OSes 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.
Thread beginning with comment 553962
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Very Impressive
by nfeske on Thu 28th Feb 2013 20:36 UTC in reply to "Very Impressive"
nfeske
Member since:
2009-05-27

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.

Reply Parent Score: 3

RE[2]: Very Impressive
by jayrulez on Thu 28th Feb 2013 20:56 in reply to "RE: Very Impressive"
jayrulez Member since:
2011-10-17

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?

Reply Parent Score: 1

RE[3]: Very Impressive
by nfeske on Fri 1st Mar 2013 10:40 in reply to "RE[2]: Very Impressive"
nfeske Member since:
2009-05-27

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.

Reply Parent Score: 2

RE[2]: Very Impressive
by renox on Fri 1st Mar 2013 15:48 in reply to "RE: Very Impressive"
renox Member since:
2005-07-06

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?

Reply Parent Score: 2

RE[3]: Very Impressive
by nfeske on Sat 2nd Mar 2013 11:14 in reply to "RE[2]: Very Impressive"
nfeske Member since:
2009-05-27

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.

Reply Parent Score: 2