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

[Luca Boccassi]

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.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220323/10544e0f/attachment.sig>