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 532351
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Good Progress
by jayrulez on Sun 26th Aug 2012 02:03 UTC 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