Roadmap 2022

[Norman Feske]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

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