Linked by nfeske on Tue 28th Feb 2012 11:51 UTC
OSNews, Generic OSes 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.
Permalink for comment 509016
To read all comments associated with this story, please click here.
RE[5]: Good
by nfeske on Wed 29th Feb 2012 18:27 UTC in reply to "RE[4]: Good"
nfeske
Member since:
2009-05-27

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.

Reply Parent Score: 1