Guest post by The just released version 12.02 of the Genode OS Framework takes the first steps to carry out the plan to turn the framework into a general-purpose OS for the daily use by its developers until the end of the year. It features a new ACPI driver, the first bits of a device-driver manager, support for using the fork syscall in GNU programs, and a PDF rendering engine. The most significant point of this release, however, is the way it was conducted. It represents the first version carried out using a completely open development process.
Since the first public release in 2008, the project was primarily driven by the company Genode Labs. Even though the complete source code of the framework accompanied with comprehensive release notes was published at quarterly intervals, design discussions and the actual development work used to happen inside the company only. In summer 2011, the developers realized that this mode of development may severe limit the reach of the project because the nontransparent way of decision-taking and developing makes it hard for people outside the inner developer circle to get hooked-on with the project. Only by making the development process transparent to the public, the project would gain a following of people actively watching its progress, bringing in new ideas, discussing issues, or even contribute. Starting in December 2011, the project has undergone the most fundamental transition in its lifetime. It left the former company-internal code repositories and issue tracker behind in order to embrace the wonderful world of GitHub. The project’s GitHub account is where the fun happens from now on.
Back to the actual release, the current line of work is primarily motivated by the road map for 2012, which envisions the use of Genode as a general-purpose OS by the end of the year. The list of working topics is the result of the developers introspecting themselves for their actual computing needs. Along those topics are features such as a PDF rendering engine and the support for the fork system call in the Noux runtime. Noux allows the use of unmodified command-line based GNU software on Genode. With the addition of fork, it has become able to execute an interactive bash shell for launching coreutils tools natively on a variety of microkernels. Given Genode’s cross-kernel portability, the most challenging part was to find a solution that works across all kernels. In the current form, OKL4, L4/Fiasco, L4ka::Pistachio, Fiasco.OC, and NOVA are supported.
Besides working on topics stated at the road map, the project continuously improves its framework APIs. The most significant new additions are a new API that exploits the C++ type system for safely accessing memory-mapped I/O resources and API support for the easy reuse of existing components as sandboxed libraries. The latter API is extensively used by the new d3m device-driver manager as well as the new ACPI driver.
These and many more improvements are described in full detail in the release notes of version 12.02.
If more developers “dog fooded” by using their own os only, it make life a lot better because things speople actually need to get productive would get worked on. I once heard a developer of a small OS say “I use Linux and only boot into <my os> to do develeopment on it”. Seriously, if your own OS isn’t good enough for you, why should anyone else care?
The problem is that turning your hobby OS in something usable (more yet with the current high standards) is a titanic task.
Genode OS guys are going by the right way!
ebasconp,
“The problem is that turning your hobby OS in something usable (more yet with the current high standards) is a titanic task.”
You got that right. For most users, what makes an OS “usable” is the apps. You might have a great functioning kernel + desktop environment, but without the apps it’s useless to a great majority of users.
Even windows itself would be useless if it were a hobby os which worked as it does now but had no software for it… The property which makes it useful is the software.
For better or worse, the only way for hobby OSes to get real apps is to run them in a compatibility layer. But implementing another OS’s APIs is a significant and thankless commitment. Look at the wine project, they’ve done a lot of good work, but it’s still hit or miss and nearly everyone buying windows software runs it on windows.
The big questions are:
How should a hobby OS dev convince users to run foreign software on a compatibility layer in the new OS?
How should a hobby OS dev convince devs to write/port software to the new OS?
Let me shed light on your questions from Genode’s point of view:
“The big questions are:
How should a hobby OS dev convince users to run foreign software on a compatibility layer in the new OS?”
Genode has not started as hobby OS. It was originally created as a tool kit to build special-purpose systems, i.e., for application areas where the use of microkernels or separation kernels is anticipated (such as high-security computing). Now the project has reached a state where general-purpose computing comes within reach. So we start to target specific end users – namely ourselves. There is no convincing needed here.
At a later stage, Genode will hopefully evolve into something that other end users will use. But they will probably not be aware of that. (similar to how many Android users are not aware that they are using Linux)
For us, end users are actually not the target audience to convince. It would be indeed near to impossible to convince them because they would not gain any functional advantage. And that’s what users ultimately care about. The target audiences are the ones who build platforms. Here the use of Genode makes a difference.
“How should a hobby OS dev convince devs to write/port software to the new OS? [/q]”
If the OS is a hobby? I think plainly, because it is fun. I am a proponent of porting existing software instead of implementing new software wherever feasible. For doing this, we don’t need to convince authors of existing (OSS/FS) projects to explicitly support our platform if their software can be integrated as is.
nfeske,
Thank you for the response! It’s very nice to hear from people directly involved.
“At a later stage, Genode will hopefully evolve into something that other end users will use. But they will probably not be aware of that.”
Some kind of special purpose rebranded OEM arrangement, I understand. Yes that does do away with the “end user problem” nicely
“I am a proponent of porting existing software instead of implementing new software wherever feasible. For doing this, we don’t need to convince authors of existing (OSS/FS) projects to explicitly support our platform if their software can be integrated as is.”
Clearly being able to run portable software helps offset the fact that not much native software is available. But it seems to me that this this might impede the development/use of more ideal/redesigned/cleaner programming interfaces for the sake of compatibility. For example, I read about your foray with the notorious “fork”. Many developers are fans of it, but many also may not realize how many subtle problems it has under the hood: threads, leaking file handles, overcommit, inefficient clone/exec sequences, etc. Also, I imagine deviating from linux’s libc, TLS and threading implementations has it’s own set of compatibility problems. Have there been instances when compatibility restraints forced you to alter your ideal implementation design?
I’m actually impressed that you guys are tackling these things and I think it’s high time complex & baggy monolithic kernels get a run for their money.
Edited 2012-02-29 15:42 UTC
Thanks for your nice words!
“For example, I read about your foray with the notorious fork. Many developers are fans of it, but many also may not realize how many subtle problems it has under the hood: threads, leaking file handles, overcommit, inefficient clone/exec sequences, etc.”
From Genode’s viewpoint, I am not a fan of fork at all because it contradicts badly with Genode’s principles (i.e., with respect to the accounting of resources). However, I recognise the beauty of its concept when looking from the perspective of the original Unix design. (although, in my opinion, this beauty was seriously spoiled with the addition of later POSIX APIs such as pthreads)
“Have there been instances when compatibility restraints forced you to alter your ideal implementation design?”
Sure. Those temptations are lurking everywhere. Fortunately, the cross-kernel portability of Genode positively reinforces careful API design. Often, taking a shortcut that works on a specific kernel would quickly solve a problem at hand. But because we need to take all the other base platforms into consideration, the costs of such narrow-sighted decisions become immediately visible. Taking fork as an example, it was not until the third attempt of implementing this feature until we found a way that would fit nicely with the existing framework design and would not need a special case for each platform. If had only one kernel to consider, we would certainly ended up with a less elegant solution.
Another pretty painful example is the C++ runtime, which is normally expected to run on top of a C library. We want to use C++ but we don’t want to have a C library as a mandatory part of the framework. Here GCC’s C++ support libraries pose a good deal of challenges. For example, during the initialization of exception support, malloc() is called. On Genode, there is no malloc(). So we have to provide a custom malloc() that uses Genode’s allocators. But those are written in C++. Chicken or egg? In this case we decided against changing GCC’s support libraries because this looked to us like opening a can of worms. Consequently, we ended up with a solution that is not completely in line with our principles. We opted for the practical way. It’s not black and white but always a question of judgement.
This is one impressive system. I am looking forward to seeing it mainstream some day.
I’ve been following the news about Genode from the beginning, and it really sounds amazing. Even the earliest demos were. I like the capability-based security model and particularly the emphasis on real-time performance. I think it would be a great OS for mobile phones. IMHO, pretty much every mainstream OS with multi-processing and virtual memory gets it wrong. There are no real-time guarantees. I mean, some do it better than others, but in the end, if there are too many processes, the OS starts to swap like crazy and ALL apps run like molasses. Not to speak of the security aspect, where you have to decide between letting every process do everything they want, or resort to complicated MAC schemes that will cause mysterious errors. Capabilities seem an obviously better approach. I’m eager to see real end-user apps, like web browsers, running as standalone Genode processes. If I understand correctly, the end user experience would be immensely better.