Release of Sculpt TC

[Paul Boddie]

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