To view parent comment, click here.
To read all comments associated with this story, please click here.
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.
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.





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.