[Tinkerphones] Librem 5

H. Nikolaus Schaller hns at goldelico.com
Sat Feb 13 22:47:01 CET 2021


Hi Mickey,

> Am 13.02.2021 um 20:28 schrieb Dr. Michael Lauer <mickey at Vanille.de>:
> 
>> But app developers (like those developing QtMoko) did expect 100% which we
>> even have not achieved many years after the active development of QtMoko ended.
> 
> Not just app developers, also middleware. In fact, the whole userland is depending on a 100%
> functioning kernel – otherwise it’s just no fun anymore.
> 
> When I was younger, I could understand the „fixation“ on getting things into mainline – now, 
> with more years on my back, I believe things would have turned out differently if we were
> to follow the path of most commercial developers – which is, freezing the kernel at one point
> of time to allow the rest of the folks to move forward without a moving target.

IMHO the solution is to do both. Try to get things upstream (so that we don't have to
maintain them any more if there are upstream modifications to include files or function
names etc) *and* try to work on a freezed kernel release.

Fortunately, this has become much easier easier than in v3.x times. Now there are longterm
stable releases and it is not that difficult to pull in upstream patches and combine them
with non-upstream stuff to make a really good and stable kernel while still participating
on security fixes and other backports that are done by the kernel community.

LetuxOS currently defines v5.4 as the current "stable" basis [1] which is not a moving target.
It works well on most hardware and isn't missing much. Even the old replicant-4.2 boots and
can be used for almost everything by using a slightly modified kernel variant.

v5.10 is the next long term kernel. Unfortunately it has some regressions and replicant still
fails boot to a user-interface (which is very difficult to debug). But it will come one day.

But generally there is no excuse not to do middleware development :)

> 
> Later on, perhaps, submit stuff upstream, jump to another mainline kernel (if necessary), rinse
> and repeat.

The problem we see with ignoring mainline movements is that there is a too big gap between
such long-term kernels like v4.19 and v5.10. This makes it really difficult to find out what
the regressions are and how to cure them. This means sticking with only one major kernel
release (let's say v4.19) works only for commercial developers who are able and want to offer
new hardware let's say every 1-2 years and then abandon all the old stuff.

Unfortunately community hardware like GTA04 or Librem 5 or PinePhone need to stay much
longer alive so that nobody would be happy if we stick too long with old kernels only...

So IMHO the strategy is to run multiple kernel variants. Fortunately, this is not as much
additional work as it looks like. This is generally manageable.

The bigger problem is to understand some subtle behaviour of hardware and kernel when it
comes to power management. And it needs permanent evaluation if it is broken by some changes.

This has become too much work for volunteers... So power management of the GTA04 is nowadays
not better (if not worse) than with the old good 3.12 kernel. But a recent kernel is much
faster and more secure and adds new functions and even enables new user-space features.

Difficult choice if we aim at optimal power management *and* optimal functionality+security :)

BR,
Nikolaus

[1]: https://projects.goldelico.com/p/gta04-kernel/


More information about the Community mailing list