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

[Luca Boccassi]

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. What matters
for core compatibility is what's the oldest in a reasonable
environment, and we know that's at 4.4. It's already quite a bump from
the current 3.13.

At least according to our documentation it wouldn't save us much
anyway, as the biggest leap is taking cgroupv2 for granted, which
requires 4.1, so it's included regardless. Unless there's something
undocumented that would make a big difference, in practical terms of
maintainability?

-- 
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/330c01e8/attachment.sig>