Release of Sculpt TC
paul at boddie.org.uk
Wed Jun 13 17:30:26 CEST 2018
On Wednesday 13. June 2018 16.02.39 Alexander Boettcher wrote:
> Hi l4-hackers,
> we are happy to announce the release of Sculpt TC , a Genode based
> incarnation of a microkernel based operating system. It is the second
> out of four Sculpt OS releases planned in 2018 .
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!
More information about the l4-hackers