OSNews

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.

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

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

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.