Linked by nfeske on Thu 23rd Aug 2012 08:30 UTC
OSNews, Generic OSes The just released version 12.08 of the Genode OS Framework comes with the ability to run Genode-based systems on ARM hardware without an underlying kernel, vastly improves the support for the NOVA hypervisor, and adds device drivers for the OMAP4 SoC. Further functional additions are a FFAT-based file system service, the port of the lighttpd web server, and support for on-target debugging via GDB.
Thread beginning with comment 532027
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Good Progress
by nfeske on Fri 24th Aug 2012 20:31 UTC in reply to "RE[2]: Good Progress"
nfeske
Member since:
2009-05-27

Apparently, the redundancies between the microkernel and the first user-land component (mostly called root task) have been somehow overlooked for years now. Not just in the context of Genode but in multi-server OS projects in general. I guess the reason is that both kind of programs used to be developed by distinct groups of people. Boldly generalizing, I think that kernel developers love to stay in kernel land. Their view is somehow narrowed to the kernel API and hardly extend to a holistic system. On the other hand, user-land developers do not challenge kernel APIs too much (similar to how most software developers rarely question the hardware interfaces underneath their software).

Personally, I find the result of the base-hw experiment quite fascinating. It shows that dissolving the barrier between thinking in categories of kernel land and user land bears the opportunity for simplifying the overall architecture.

I share your observation about several of the base platforms. The motivation for keeping them around slightly differ from kernel to kernel. For Codezero, we are still hoping for a relaunch of the kernel as an Open-Source project. Pistachio is actually still maintained. For all of those kernels, there are also common reasons to not abandon them.

First, its beneficial for Genode's API design. Each kernel poses different challenges with regard to implementing the API. By accommodating a variety of kernel interfaces, we constantly reassure the portability of the framework and force ourself to find clean solutions that work across all of the kernels.

Second, having an arsenal of kernels at our disposal is just great for cross-correlating the behaviour of the system during debugging. Many bugs can be tracked down by just looking at the differences of executing the same scenario on different platforms. In fact, at Genode Labs we are constantly switching between the kernels including the ancient L4/Fiasco kernel. As a bonus, several of the kernels offer unique debugging features, which become pretty handy from time to time.

Third, maintaining support for an already supported base platform is cheap. It comes down to maintaining approximately 2000-3000 lines of code per kernel. For a kernel that won't move, the maintenance costs are almost zero (except for changes of the Genode API).

Reply Parent Score: 2

RE[4]: Good Progress
by jayrulez on Sun 26th Aug 2012 02:03 in reply to "RE[3]: Good Progress"
jayrulez Member since:
2011-10-17

Thank you for clearing that up. Would I be right to say that the platforms that are better supported at the moment are NOVA and Fiasco.OC?

I read somewhere that NOVA is the platform that NOVA is the kernel that most naturally fits with the design of Genode. Could you compare the level of support for these two kernels (Fiasco.OC and NOVA).

Also, would it be feasible to fork a kernel with support for a wide range of architectures e.g. Fiasco.OC and modify it to be more deeply integrated with Genode in order to eliminate some of the duplication? (Promoting it to a first class citizen in the framework.)

Regarding base-hw: Since the kernel and core are now running in the same address space, is this against one of the philosophies Genode i.e. the isolation of subsystems/components? Is running them in the same address space just an interim solution or is that the way forward?
I believe that since kernel and core are both critical to the system then it makes sense to integrate them if it reduces the complexity of the TCB.

Reply Parent Score: 2

RE[5]: Good Progress
by nfeske on Mon 27th Aug 2012 11:40 in reply to "RE[4]: Good Progress"
nfeske Member since:
2009-05-27

"Would I be right to say that the platforms that are better supported at the moment are NOVA and Fiasco.OC?"

Yes, in particular when looking at the security model. Those two kernels support Genode's way of delegating access rights throughout the system at kernel level, which makes them naturally a good fit for the framework. If factoring out the security aspect, there are other kernels that cover the whole Genode functionality as well. For example, on OKL4 or L4/Fiasco, the whole Genode API is fully functional. Linux is also pretty well supported in terms of stability but, of course, it is inherently limited to the features offered by the Linux kernel. For example, because there is no way to manipulate an address space of a remote process, Genode's managed dataspace concept won't work on Linux.

"Could you compare the level of support for these two kernels (Fiasco.OC and NOVA)."

With the current release, both base platforms are almost on par. Fiasco.OC has a slight edge with regard to the life-time management of kernel resources but we are working on getting the NOVA base platform there, too.

"Also, would it be feasible to fork a kernel with support for a wide range of architectures e.g. Fiasco.OC and modify it to be more deeply integrated with Genode in order to eliminate some of the duplication? (Promoting it to a first class citizen in the framework.)"

Personally, I don't feel the slightest temptation to do so. ;-) The F/OSS microkernel community is small enough, and actually quite fragmented. A fork would not only be a step in the wrong direction, it would pose a big liability for the forking project. We should better try to discuss our findings with the respective kernel developers to elaborate ways of how the redundancies can be reduced by changing the kernel API. For example, from Genode's perspective, the in-kernel mapping database as featured by both Fiasco.OC and NOVA is more of a hindrance than a feature. So we would try to convince the kernel developers to remove it or to make it optional. We are actually in close contact with NOVA's developers, discussing such ideas.

"Is running them in the same address space just an interim solution or is that the way forward?"

As both components are always forming the root of the process tree, there is no security benefit of separating them. Speaking from Genode's perspective, putting them into a single component is clearly the way to go. From the perspective of kernel developers, this is not so easy because each kernel tries to accommodate user-land implementations other than Genode as well.

Reply Parent Score: 1