Hi Stefan,
Nevertheless, this line of work prevented me to achieve the unification of the platform driver API across different architectures in time. Although it is almost accomplished, the original goal was to finish it in 21.05. Inwardly, I dreamed of having a working Wifi card in Sculpt on the MNT Reform 2 at this time, which is not the case.
there should be no reason for any regrets. Plans change, in your case for very good reasons. Your work on DDE-Linux evolved into a much more profound project than I imagined, and I'm super happy and proud about it. Also, I think that our vision of the role and design of the platform driver was too uncertain to make definite a-priory estimations. The design that emerged over the past year vastly exceeds the old - in many places ad-hoc - nature of the traditional platform driver.
I encourage you to keep up following the goal to make Genode on the MNT-Reform fully capable, including Wifi. This is of course out of selfishness. I love the MNT-Reform laptop. I'd love it even more with wireless connectivity on Sculpt :-)
I would not call them road blocks, but while analyzing the requirements of a re-newed platform driver implementation, I was wondering whether we still need to support ancient kernels like Pistachio, or the old Fiasco. Apart from the dependencies on quite old hardware of these kernels, a lot of workloads are not possible to run on them. We have to ignore the nightly kernel faults etc. of especially Pistachio. Therefore, I would suggest to retire these kernels within 2022.
This line of reasoning is certainly valid because those old kernels won't play any practical role for real-world Genode scenarios.
However, I don't share the sentiment to retire them because I still get a lot of value from the diversity of kernels, when compared to the costs of maintenance. Let me share what those values are:
- When working on the base-framework infrastructure, I'm forced to apply all changes in a way that is workable with all the different kernels. This (arguably artificial) problem challenges me to re-evaluate changes repeatedly and from different perspectives. The repetition has become some kind of Zen when working on the base framework. Sometimes, I stop applying a change mid-way for the better because applying one idea 8 times makes one critically evaluate the idea 8 times in a row. ;-)
In your case - looking at IRQ support on PIC vs. IOAPIC - the (useless at surface level) support for plain PIC-based systems is additional work. But if we manage to cover it in an elegant way, the result will be more general and sustainable. So I invite you to accept this challenge.
- The diversity of kernels fuzzes our system and uncovers issues - often related to generic code - that would remain unknown to us without the broad spectrum of hardware/kernel combinations regularly exercised. Yes, we see kernel assertions triggered by a few tests that won't ever be fixed. But on the other hand, when assessing a regression, the cross-kernel test results often allow me to cross- correlate the behavior, and form a mental model of what could be wrong. E.g., if I see a test failing on all kernels that use s mapping database, I can form a hypothesis.
- During the development of low-level features - the fork mechanism of the libc comes in mind - it is best to start with the simplest kernel possible. E.g., on OKL4 I can readily use the Genode::raw mechanism, and can easily track capabilities across PDs because they are just global numbers. Such developments would be far more complicated on a real capability-based kernel.
- There are still some areas where we haven't yet learned all the lessons the kernels can teach us. Specifically, there still exist unexplained performance anomalies between kernels, e.g., when looking at network throughput. The performance tends to be influenced by details of the kernels scheduling. We should strive to refine Genode such that those anomalies eventually disappear, making the framework as deterministic as possible against the whims of the various kernel schedulers. Until that point is reached, it is good to keep the anomalies clearly visible and reproducible.
Other (sometimes surprising) effects occur because of different approaches when comes to cache attributes, or the choice of time source (PIT as scheduing timer).
- I actually used the L4/Fiasco kernel debugger in 2021. Not a strong argument, but still worth noting.
- Being the one with most time invested refining the base framework over the past year, I found the costs of maintenance of the legacy kernels pretty much negligible compared the grand scope of changes. I'd be fine with kicking this can further down the road.
So my position to keep the kernels supported is not merely some weird nostalgic attachment that I feel for those relics, but I see actual technical value of keeping them around.
Cheers Norman