On Wednesday 13. June 2018 16.02.39 Alexander Boettcher wrote:
Hi l4-hackers,
we are happy to announce the release of Sculpt TC [0], a Genode based incarnation of a microkernel based operating system. It is the second out of four Sculpt OS releases planned in 2018 [1].
It is certainly interesting to see progress being made with Sculpt and Genode. Although my own investigations have been conducted using L4Re, I did consider doing some coding with the Genode framework, but I found the documentation to be a bit hard to navigate for what I wanted to discover.
That said, it has taken a while for me to navigate the L4Re documentation in a half-way effective fashion, so I rather get the impression that I might not be amongst the target audiences for some of the materials being produced. Ultimately, I didn't see a compelling reason to switch to Genode from a perusal of the documentation and the code for a number of reasons.
Firstly, as the list members reading my messages can attest, having had to endure them, I have been using Fiasco.OC because it supports the MIPS architecture. I see that Genode supports a selection of microkernels, but this support appears rather inconsistent, and I suppose this is the reason why Sculpt only targets x86_64. I also see that seL4 has a place in the Sculpt roadmap, but this only broadens the architecture support to two or three architectures. What would be needed for it to work with Fiasco.OC?
A related issue is how I might work with Fiasco.OC within the Genode framework. There appears to be some kind of "preparation" involved which itself involves cloning a personal repository (on GitHub - sigh!) that was, last time I checked, rather old. I quickly became concerned that managing my own patches on top of Fiasco.OC would get even more complicated.
My initial impression is that Genode seems to have a more developed driver framework than L4Re and attempts to support applications that more closely resemble those on conventional desktops. It should almost be a foregone conclusion that I might choose Genode, particularly since things like Qt seem to be available, which I imagine would appeal to various audiences.
However, regarding the drivers, there seems to be a focus on Linux drivers. I find this a bit baffling because my own experiences with Linux drivers indicate that there is a lot of technological churn, copy-paste coding (although that has improved in some areas), and the driver frameworks themselves can cause a lot of additional complication.
Is this focus on Linux pursued because people would then expect the sudden availability of contemporary hardware support if such drivers can be adapted in some way? It seems to me that this never works out very well because soon enough one is left with, say, adapted 2.6-era drivers that cannot be updated because Linux itself has moved on, and with the point of adapting the drivers being that no-one has to concern themselves with how they function, no-one is able to overhaul them, either.
(Admittedly, my own experiments concern hardware that is well-enough documented and has seen several iterations of driver support that writing new drivers should be feasible even for someone like myself. Still, I think that developing "generic" driver components is the sustainable way forward.)
It might also be interesting to see how the mechanisms in Genode and L4Re compare to each other, and how these systems relate to multiserver systems like GNU Hurd both technically and in terms of ambition, but I find myself writing too much once again. Any clarifications on areas in which I am mistaken would be very welcome, however!
Paul