[systemd-devel] Antw: [EXT] Re: version bump of minimal kernel version supported by systemd?

[Ulrich Windl]

I wonder:

Why not providing some test suite instead: If the test suite succeeds, systemd
might work; if it doesn't, manual steps are needed.
My guess is that most people will quit trying once manual steps are needed.
In addition the configure procedure could include a "support window" (oldest
kernel supported, latest kernel supported).
And f the kernel is outside, print a warning at least that the configuration
is not supported.
Still I guess the kernel version is not the only dependency...

Regards,
Ulrich

>>> Luca Boccassi <bluca at debian.org> schrieb am 23.03.2022 um 16:58 in
Nachricht
<4b96e540891ee7a43917ba377806e520a0d7be02.camel at debian.org>:
> 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