Release of Sculpt TC

[Paul Boddie]

On Friday 15. June 2018 00.17.49 Alexander Boettcher wrote:
> On 13.06.2018 17:30, Paul Boddie wrote:
> > 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.
> 
> Sorry to hear that you're not comfortable with our documentation.
> Constructive criticism is welcome and will certainly increase the
> quality of the documentation in the future. Unfortunately, we must
> missed your mails so far.

Are you referring to my mails to the l4-hackers list or some other mails?

> Some notes for the target audience:
> 
> Genode framework documentation sources are:
> 
> - the Genode foundations book -
> https://www.genode.org/documentation/genode-foundations-18-05.pdf -
> updated every year
> - the 3 monthly release notes -
> https://www.genode.org/documentation/release-notes/index
> - and further more - https://www.genode.org/documentation/index
> 
> The Genode book is considered (as told us by externals repeatedly) as
> unique feature among the other projects in this area. It is a very good
> starting point.

I'll be sure to take a closer look at it.

> The 3 monthly release notes of Genode are a comprehensive description of
> the most prominent changes between the releases - in textural and mostly
> in graphical form.
> 
> The spectrum of documentation varies of course between projects, but I
> wouldn't consider Genode at the lower end of the spectrum.

My observations were not intended to criticise the quality of the 
documentation.

> What you also may can get: no documentation (or at least not publicly
> available), or just source code dumps without any release notes or if
> you're lucky squashed together commits as kind of release notes. There
> are further bizarre combinations imaginable.

Yes, there is a lot of variation when it comes to software documentation.

> > 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.
> 
> If you want to reach a broad audience to show the potential of Sculpt
> TC, MIPS or ARM machines are not that common on a normal user desk. A
> spare x86 machine and/or ready-to use x86 virtualization solutions are
> around the next corner.

I happen to have some MIPS-based devices lying around, and they seem to be 
reasonable candidates for experimentation, at least for me. It gets them into 
some form of use, I suppose. But I suspect that I am not really part of the 
primary audience for these and other reasons.

> Second, supporting and testing all combinations of architectures and of
> kernels in the first evolution steps of Sculpt is economically absurd,
> but this is obvious.(Actually, there are many ready to use packages
> around for the other kernels and architectures of course.)

I know what you mean. I have previously written software that aimed to support 
a selection of library/framework foundations in order to deliver a coherent 
interface for application-level software. I'm not sure I would rush into doing 
something similar again.

> Third, unfortunately - not all supported kernels are fit enough to
> survive the heavy dynamic load put on them by Sculpt/Genode. Reasons are
> manifold, reaching from kernel crashes&bugs over to not yet enabled
> features because of missing time or interest or investment or all of them.

Some of the kernels supported by Genode are surely more mature than others, 
though. I guess that for those more mature kernels, it is mostly a question of 
interest.

> The officially supported architectures and kernels for Sculpt may of
> course change/increase, but this depends on various (internals as
> externals) factors - time will tell us.
> 
> > What would be needed for it to work with Fiasco.OC?
> 
> Interest. Over the last years the interest in Genode/Fiasco.OC decreased
> to a very low point. Still, we are happy about contributions and are
> willing to maintain it as resources permit. The Sculpt setup is not
> seriously in reach.

OK. I think this answers a central question of mine quite definitively.

> > However, regarding the drivers, there seems to be a focus on Linux
> > drivers. I find this a bit baffling.
> 
> Sorry - lol - never could imagine anybody from the sphere of L4Linux's
> home is baffled about driver code from Linux.

I meant that I find the strategy baffling, not that anyone interested in 
driver development would necessarily find Linux driver code baffling as such. 
If this was amusing in some way, I assure you that it was unintentional.

Note that I don't have any real interest in, or experience with, L4Linux. 
Personally, I don't really see much point in deploying Linux on top of a 
hypervisor, but I understand that this is all the rage these days.

> First of all, our drivers are running natively, so we don't require any
> kind of (para-)virtualization solutions to get driver support.
> 
> Second, we tend to write our driver ourself, if economically justifable
> and maintainable, like for NVMe, AHCI, SD/CARD, PS/2, ACPI, GPIO, UART,
> graphic driver on some ARM board, timers, ... (and the others I forgot
> and just heard about it).
> 
> Resource multiplexer are all self-written - like network, disk and
> graphic. (a self-written GPU multiplexer is also around).
> 
> Other ported drivers from NON-Linux projects are audio and network.

OK. So, having a bit more familiarity with L4Re, I perceive this collection of 
software as being somewhat equivalent to the various components that L4Re 
attempts to provide. (Not necessarily in terms of breadth of coverage or depth 
of functionality, however.)

> Drivers ported from Linux running isolated as native Genode components
> are USB, WIFI (+WPA2), Intel graphic cards and one ARM network card.
> 
> I don't get your point.

My point was that I saw a focus on Linux drivers in the documentation and 
assumed that this was possibly the principal vehicle for introducing broader 
hardware support more efficiently than attempting to write new drivers.

> > enough one is left with, say, adapted 2.6-era drivers that cannot be
> > updated because Linux itself has moved on
> 
> Don't know who supports seriously 2.6-era drivers - our Linux based
> ported drivers are based on 4.4+ and will get updated shortly to a more
> recent Linux version.

This is interesting to hear about. With regard to 2.6-era drivers, few people 
seriously support them any more, of course, but I seem to recall various 
projects employing device driver environments that had their origins in the 
Linux 2.6 era. (This is a stated issue with GNU Hurd, for instance, although 
the situation there is gradually changing.)

But regardless of the specific version from which any drivers may originate, a 
commitment must presumably be made to track changes in the frameworks employed 
by the drivers themselves. Maybe this isn't much of a challenge and is 
therefore not a big problem, or maybe those driver environments were just 
unlucky to adopt drivers from before one of the periods of upheaval in Linux 
driver development.

> > Any clarifications on areas in which I am
> > mistaken would be very welcome, however!
> 
> Done.

Thank you for the reply. It certainly tells me quite a few things I need to 
know about this software.

Paul