Relationship with kernel

Posted Nov 5, 2025 17:49 UTC (Wed) by SLi (subscriber, #53131)
Parent article: A security model for systemd

I know this is neither the intent nor quite true, but one gets the feeling that the mentality is a bit of a resigned "this is what the kernel folks have decided to give us, and we'll do our best with it"—i.e. there's a large development barrier between systemd and the kernel. This is, of course, probably both good and bad; but given that systemd is relatively central to modern Linux systems, do you think it would make sense to even try to develop them together? If not now, then at some point in the future?

Now it has a bit of a feeling of waterfall development with agreed responsibilities and "you stay there, I stay here".

I'm not even saying this is bad. It's actually very good that the userspace/kernel API gets defined well and narrowly. Rather, do you see this as a hindrance?

Relationship with kernel

Posted Nov 5, 2025 18:17 UTC (Wed) by bluca (subscriber, #118303) [Link]

Fortunately it is not quite the case, generally speaking. Lots of stuff gets added because we ask for them and are the primary users - see most of the PID FD interfaces that were added in the past few years, and lots of cgroups stuff before that too.
However, there are tons of _existing_ interfaces/systems/whatnot that can't really change, as it would be a massive compat break to do so, and an humongous task on top of that, so it is true that we are resigned to e.g. file caps being what they are.
Adding new things is much much easier than changing existing, entrenched subsystems.

So as always it's nuanced, and there's a bit of both at play.