norman.feske at genode-labs.com
Wed Jan 5 12:34:52 CET 2022
> 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
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.
Dr.-Ing. Norman Feske
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users