[systemd-devel] version bump of minimal kernel version supported by systemd?

Wed Mar 23 21:11:36 UTC 2022

On Wed, Mar 23, 2022 at 03:58:22PM +0000, Luca Boccassi wrote:
> On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote:
> > On Wed, Mar 23, 2022 at 11:28:29AM +0000, Luca Boccassi wrote:
> > > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote:
> > > > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote:
> > > > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > > we are considering dropping upstream support for kernel versions < 4.4.
> > > > > > > > Would this be a problem for anyone? (*).
> > > > > > > 
> > > > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel
> > > > > > > 4.4, why not just move to not supporting kernels older than 4.9?
> > > > > > 
> > > > > > It seems Civil Infrastructure Platform (a project under the Linux
> > > > > > Foundation) still uses 4.4 [1].
> > > > > 
> > > > > Yes, but they are not going to be updating to a newer version of
> > > > > systemd, right?
> > > > > 
> > > > > And they are going to be "supporting" that for 20+ years.  If they want
> > > > > to do something crazy like this, make them handle supporting code that
> > > > > is older than 6+ years to start with.  That's not the community's issue,
> > > > > that's the companies that demand such crazy requirement's issue.
> > > > 
> > > > That's why I (we) asked the question on the list. If people are compling
> > > > systemd on such old systems, or even older, we want to know about it.
> > > > 
> > > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9,
> > > > > > and after that Buster has 4.19.
> > > > > 
> > > > > 4.9 is fine, and is supported by kernel.org until next year as seen
> > > > > here:
> > > > > 	https://kernel.org/category/releases.html
> > > > > 
> > > > > I wrote "4.9" above, not "4.19" :)
> > > > 
> > > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up.
> > > > 
> > > > Zbyszek
> > > 
> > > Let's do 4.4 at most please - what's on kernel.org is not really that
> > > important, as real usage is downstream from there anyway.
> > 
> > And I will publically state that anyone still using 4.4.y today has an
> > insecure and unsupported system.  Please let's not encourage _ANYONE_ to
> > do this.
> > 
> > CIP is "special" in that they know what they are doing, and are using
> > 4.4.y in a very limited set of use cases and configurations.  And even
> > they are going to have big problems keeping that kernel alive and
> > secure.  I would never expect anyone else to be able to do it, and I
> > have doubts that they will either.
> > 
> > So any "real usage" of 4.4 after today, should not matter.  And if
> > someone complains, send them to me please.
> > 
> > thanks,
> > 
> > greg k-h
> 
> You can publically state that all day long, but you know perfectly well
> that's not how the world works. In the grand scheme of things few
> production scenarios build their kernel from kernel.org, most will be
> getting it from a distro (best case) or a vendor (worst case), and they
> couldn't care less about what kernel.org tells them to do, they use
> what they get. I fully expect at some point to hear complaints from
> some poor soul stuck on 3.x because of $crappy_arm_vendor with no way
> to move on from there.
> 
> Jumping forward from 3.13 to 4.4 as the baseline, allowing to take
> cgroupsv2 for granted, seems like a good starting point to me. There's
> very obvious and public evidence of that being used in the wild. We can
> start to drop a bunch of backward-compat cruft, wait and see who
> complains, and if nobody does we can re-evaluate again in a couple of
> years.

Yeah, but I don't think we want to go through this exercise again in a
few months. If we jump, we might as well jump a bit further.

CIP 4.4 is supposed to be maintained until 2027, which is awfully
long. The question is: is anyone putting new systemd on those
systems?  If no, then they're not relevant.

Or in other words: I'd prefer for such people to speak up for
themselves, rather than us trying to figure out what somebody else
*might* be planning to do.

Zbyszek