Systemd discusses its kernel-version needs [LWN.net]

Systemd discusses its kernel-version needs

Posted Mar 31, 2022 7:14 UTC (Thu) by LtWorf (subscriber, #124958)
Parent article: Systemd discusses its kernel-version needs

> Kroah-Hartman seemed surprised to hear that, since the kernel developers take user-space compatibility seriously. As readers of the LWN kernel page know, Linus Torvalds will quickly step in and remind kernel developers, sometimes rather harshly, that the kernel does not break user space.

A large asterisk is required there. They mean this for kernel API, but have no problem in continuously moving around stuff in /proc and /sys making configuration scripts require constant maintenance.

> The kernel-upgrade resistance is something that the stable maintainers (and others) have been struggling with for a long time

It happened to me quite recently that they released a kernel with a buggy intel driver so my machine took about 20 minutes to reach the login screen and was so slow to be completely impossible to use.

Had to revert to an older kernel.

to post comments

Systemd discusses its kernel-version needs

Posted Mar 31, 2022 13:58 UTC (Thu) by corbet (editor, #1) [Link] (2 responses)

/proc and /sys are definitely considered part of the user-space ABI. Have you reported changes that caused you problems? That really isn't meant to happen.

Systemd discusses its kernel-version needs

Posted Apr 1, 2022 4:31 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (1 responses)

But in fact it does happen because some old interfaces become deprecated, and others are bogus and eventually get fixed. For example I've been training my fingers to read the battery state on my laptop by doing "cat /proc/acpi/battery/BAT0/state" for more than a decade, and recently after upgrading to 5.10 I finally lost it, and now have to read several files in /sys.

Similarly some entries in /sys used to be misdesigned, with multiple values in the same entry, which is contrary to the /sys design rules. Some of them were finally fixed and split into multiple entries.

Some quickly written scripts that rely on these entries may occasionally break.

The bonding configuration interface changed over time to only use /sys. In the past you would pass arguments to modprobe then use ifenslave to configure the interface (but that wouldn't scale to multiple interfaces). Similarly code written for this eventually had to be changed.

There are definitely situations that cause visible breakage. It's not necessarily a regression but often the replacement for something wrong that cannot be supported anymore and that very limited stuff used to rely on. And these changes do require extra validation on upgrades that cannot make them 100% transparent. That's why LTS kernels are much appreciated for deployment in remote devices at customers'. They limit the risk of surprise on a supposedly harmless upgrade.

Systemd discusses its kernel-version needs

Posted Apr 2, 2022 1:14 UTC (Sat) by alison (subscriber, #63752) [Link]

Looks like /proc/acpi has a tortured history. 7d7ee958867a in 2013 says

commit 7d7ee958867ad3c9c829a36c56e870879e83391f
Author: Lan Tianyu
Date: Fri Oct 11 09:54:10 2013 +0800

ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c

There is no user of cm_sbs.c and CONFIG_ACPI_PROCFS_POWER. So remove
them. Prepare for removing /proc/acpi

...That patch was reverted in 2014:

commit e2a7c3d7812369daae56f069eab2e8f3e548d231
Author: Lan Tianyu
Date: Sun May 4 11:07:24 2014 +0800

ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"

The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery
directory and breaks some old userspace tools. This patch
is to revert 7d7ee95.

...Then in 2018 the documentation was updated, but /proc/acpi continued onward:

commit 7e46b32bd58768b4823e767dc14d88ab59c6902e
Author: Randy Dunlap
Date: Fri Mar 2 16:55:54 2018 -0800

ACPI / Kconfig: Update ACPI_PROCFS_POWER help text

Fix grammar and punctuation (end sentences with a period) in the
Kconfig help text for ACPI_PROCFS_POWER.

I was looking at this since it appears to be going away (again,
some day) and I have a working script that uses this info to tell me
battery usage. I can update the script to use /sys/class/power_supply
(in theory) but the contents (with units) should be documented in
Documentation/ABI/ before /proc/acpi/battery/ is removed (IMO).</p>

..."Some day" turned out finally to be 5.10. The kernel does sometime "break userspace," but not usually in any haste.

Systemd discusses its kernel-version needs

Posted Apr 1, 2022 5:41 UTC (Fri) by donald.buczek (subscriber, #112892) [Link]

> > The kernel-upgrade resistance is something that the stable maintainers (and others) have been struggling with for a long time

> It happened to me quite recently that they released a kernel with a buggy intel driver so my machine took about 20 minutes to reach the login screen and was so slow to be completely impossible to use.

We've hit so many regressions updating to newer (stable!) releases, that a kernel update is considered a risk and generally avoided. Kernel developers focus on improvements instead of quality and stability. Bug fixes are interwoven with refactoring and new ideas, so that even in stable releases old bugs are just replaced with new bugs. Some subsystems have just a single active developer and there are not enough independent reviews. The kernel is moving to fast for the developers to sustain or improve quality.

Bugs from mainline are backported into stable releases or are just inherited when a new stable branch is forked. "Stable" doesn't help you much, because sooner or later you need to leave your stable branch anyway and the longer you wait with that, the further you leap and the more problems you have all at once.