Systemd catches up with bind events

Posted Nov 14, 2020 2:23 UTC (Sat) by koh (subscriber, #101482)
In reply to: Systemd catches up with bind events by rahulsundaram
Parent article: Systemd catches up with bind events

The kernel has lots of interfaces where stuff keeps getting added and therefore has to be considered as an open set: syscalls, flags to syscalls, the sysfs entries, filesystems, modules, etc. How is this set of event types any different? If someone was to create a userspace program relying on a particular syscall, flag, whatever, not being implemented - until it finally is - would that be a regression?

to post comments

Systemd catches up with bind events

Posted Nov 14, 2020 3:12 UTC (Sat) by khim (subscriber, #9252) [Link]

> If someone was to create a userspace program relying on a particular syscall, flag, whatever, not being implemented - until it finally is - would that be a regression?

Absolutely. LWN even have article which explains how and why that case should be handled.

But there is also the rule if nobody notices, it's not broken.

Now… we have very weird corner-case: somebody have noticed… year after the change was made. That's… rather unusual, to say the least.

Systemd catches up with bind events

Posted Nov 14, 2020 8:42 UTC (Sat) by abo (subscriber, #77288) [Link] (1 responses)

Try booting RHEL8 (or derivatives) on the latest upstream kernels. It will initially appear to work, but certain systemd operations will fail due to a change in capabilities. (https://bugzilla.redhat.com/show_bug.cgi?id=1853736)
The fix in that case is a lot simpler, and backporting it to various distro systemd versions isn't a big deal, but it's still a regression.

Perhaps it is reasonable to consider systemd exempted from the kernel's ABI/API stability promise, because it is sometimes almost the only user of certain interfaces?

Systemd catches up with bind events

Posted Nov 15, 2020 15:19 UTC (Sun) by pbonzini (subscriber, #60935) [Link]

> Perhaps it is reasonable to consider systemd exempted from the kernel's ABI/API stability promise, because it is sometimes almost the only user of certain interfaces?

That's complicated. With more and more people using containers—including OS containers running a full-blown init system—it's not that rare to see very new userspace on old kernels or vice versa. This also means that it will be much harder to remove features in distro kernels: for example, even if your distro ships with an nftables-based iptables(8), there could be containers using the older iptables API.