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.

I am concerned about the duplication of efforts to manage resources in the kernel and core when using the other platforms.

Consequently, we found several information replicated without a clear benefit. With this comes a seemingly significant redundancy of code for data structures, allocators, and utility functions. Furthermore, there exists a class of problems that must be solved by the kernel and core alike. In particular the resource management of dynamically allocated in-kernel objects respectively in-core objects. Whereas core uses Genode's resource-trading concept to solve this problem, most kernels lack a good solution for the management of in-kernel resources and are consequently prone to resource exhaustion problems.

Is there any plan to to address that problem base platforms other than base-hw?

Another area of concern is the supported base platforms. Some of the supported kernels do not seem to be developed anymore or are no longer open source. E.g. Codezero, Pistachio, OKL4 and the old Fiasco. Also, Codezero also seem to offer a subset of the features of Fiasco.OC.

From what I understand, the wide variety of kernels helps to produce ideal design decisions in genode that are applicable across platforms. Is there any other merit in continuing to develop genode on those platforms?

Congratulations on the new release and the detailed release notes. They are always interesting to read. Genode is an excellent project and I am looking forward to seeing it widely deployed in the future.

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).

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.