[systemd-devel] Antw: Re: Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
>>> Lennart Poettering schrieb am 01.04.2022 um 14:18 in Nachricht : ... > time. Often for good reasons, quite often also for no reason but lack > of testing. Things like that will happen. But I also think that > Windows for example is probably better at not breaking their > interfaces than Linux is. Nonsense: I had several Windows program that did not work correctly any more when moving to the next version of Windows. In the second to next version, some of the programs worked again! (I'm not talking about monthly updates, I'm talking about really new versions) > > Lennart > > ‑‑ > Lennart Poettering, Berlin
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
On Fr, 01.04.22 13:54, Greg Kroah-Hartman (gre...@linuxfoundation.org) wrote: > > While it is true that the syscall interface is kept reasonably stable, > > almost everything else gets monkeyed with a lot, because a lot of > > kernel developers only consider the syscall interface a program > > interface. This is a problem because a *lot* of things are only > > accessible through other means (procfs, sysfs, uevents, etc.). > > > > Unfortunately, that means that in practice, the kernel interfaces that > > userspace *must* depend on break far more than anyone likes. > > The above example is an interesting case. A new feature was added, was > around for a while, and a few _years later_ it was found out that some That's not quite true. The breakages were actually reported pretty quickly to the kernel people who added the offending patches, and they even changed some things around (an incomplete patch for udev was posted, which we merged), but the issue was still not properly addressed. It died down then, nothing much happened, and udev maintainers didn't bring this up again for a while, as they had other stuff to do. The issue became more and more visible though as more subsystems in the kernel started generating these uevents, to a point where ignoring the issue wasn't sustainable. At that point kernel people were pretty dismissive though (not that they were particularly helpful in the beginning either), partly because the change was in now for so long. So we reworked how udev worked. > people had userspace "scripts" that broke because the feature was > added. nah, this broke C code all over the place, too. Not just "scripts". I am not even disagreeing though that bind/unbind uevents made sense to add. I just want to correct how things happened here. There was a general disinterest from the kernel people who broke things to fix things, and in particular major disinterest in understanding how udev actually works and how udev rules are used IRL. (I mean, that early patch we got and merged literally just changed udev to drop messages with bind/unbind entirely, thus not fixing anything, just hiding the problem with no prospect of actually making it useful for userspace. I figure the kernel devs involved actually cared about Android, and not classic Linux userspace, i.e. udev.) I know the kernel people like to carry that mantra of not breaking userspace quite like a monstrance, but IRL it's broken all the time. Often for good reasons, quite often also for no reason but lack of testing. Things like that will happen. But I also think that Windows for example is probably better at not breaking their interfaces than Linux is. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
On Fri, Apr 01, 2022 at 07:39:25AM -0400, Neal Gompa wrote: > On Thu, Mar 24, 2022 at 8:15 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Mar 24, 2022 at 10:23:21AM +, Luca Boccassi wrote: > > > On Thu, 2022-03-24 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > On Thu, Mar 24, 2022 at 09:33:50AM +0100, Ulrich Windl wrote: > > > > > > > > Greg KH schrieb am 24.03.2022 um > > > > > > > > 08:12 in > > > > > Nachricht : > > > > > > On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: > > > > > > > FWIW, I think Greg was a bit too outspoken calling long > > > > > > > maintenance > > > > > > > attempts 'crazy'; that may have intimidated some. I'm thinking of > > > > > > > moving distro to one that provides longer term maintenance than my > > > > > > > present one. Although CIP is a completely different ball game; I > > > > > > > hope > > > > > > > they succeed. > > > > > > > > > > > > It is not "crazy" it is "well documented". As someone who has been > > > > > > doing this work for 20+ years now and sees all of the stable kernel > > > > > > patches flow by, it's obvious that a distro that does not keep up > > > > > > with > > > > > > them is insecure by design. > > > > > > > > > > If "newer is better" I'd agree. Sometimes "newer is actually worse". > > > > > Some new features intended to improve things sometimes actually make > > > > > things worse. > > > > > > > > That's not the issue here. > > > > > > > > Do you want to run a kernel with known security problems, or one with > > > > "unknown potential problems." The latter is always the case, so please > > > > don't pick the known-insecure one, that's just foolish. > > > > > > "security problems" are a dime a dozen, as they say. Speaking as a > > > (thankfully former) downstream integrator, you'd have much more success > > > if you stopped breaking backward compatibility with userspace all the > > > damn time. Upgrading major kernel version is like rolling a dice, you > > > never know what kind of extremely expensive and time consuming rabbit > > > hole you'll be dragged into because the kernel plays fast and loose > > > with its userspace interfaces, and each and every time there's a chance > > > one might end up having to do major reworks to deal with it. > > > > We should never be breaking working userspace programs when upgrading > > the kernel. If so, please report it to the regressions mailing list. > > > > Of course there's always some corner cases, but for the most part, this > > should never happen. > > > > > So really it shouldn't be that surprising that users are averse to > > > following the "latest is greatest" mantra from kernel.org, given how > > > risky and expensive it is, and how little one gains in return. Rather > > > than changing the world, what about changing your own processes first? > > > A great starting point would be reverting backward incompatible changes > > > regardless of who's affected, instead of doing that only if they affect > > > the personal computer of a handful of maintainers (mainly Linus'), and > > > shrugging reports away with "deal with it" in other cases. > > > > We should never be "shrugging" away reports like this. If you have > > specific incidents that you wish to discuss, I will be glad to do so on > > the regressions kernel mailing list. Otherwise this is way off-topic > > for systemd-devel. > > > > >From a systemd-relevant angle, this has happened before. Recently > even: > https://github.com/systemd/systemd/blob/8c70e8024ba8ff42c23f1a35b9e8fafddd5caa8d/NEWS#L2355-L2437 (for those that don't want to look this up, it's the BIND/UNBIND uevent issue.) > That means that from a reasonable systemd user perspective, we need to > depend on Linux kernel 4.14 or higher to cross over that breakage. Great! :) > While it is true that the syscall interface is kept reasonably stable, > almost everything else gets monkeyed with a lot, because a lot of > kernel developers only consider the syscall interface a program > interface. This is a problem because a *lot* of things are only > accessible through other means (procfs, sysfs, uevents, etc.). > > Unfortunately, that means that in practice, the kernel interfaces that > userspace *must* depend on break far more than anyone likes. The above example is an interesting case. A new feature was added, was around for a while, and a few _years later_ it was found out that some people had userspace "scripts" that broke because the feature was added. Yet people had already started depending on this feature, and really, the "broken" scripts had always been broken, they just worked accidentally by virtue that userspace was assuming the type of uevent that was happening. So what would you do if you were in my position? We can't break existing userspace tools that relied on the new events, and yet upgrading the kernel broke older tools if they were not changed. Anyway, fixing the scripts worked for everyone, and I think systemd did the right thing
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 8:15 AM Greg Kroah-Hartman wrote: > > On Thu, Mar 24, 2022 at 10:23:21AM +, Luca Boccassi wrote: > > On Thu, 2022-03-24 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > On Thu, Mar 24, 2022 at 09:33:50AM +0100, Ulrich Windl wrote: > > > > > > > Greg KH schrieb am 24.03.2022 um > > > > > > > 08:12 in > > > > Nachricht : > > > > > On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: > > > > > > FWIW, I think Greg was a bit too outspoken calling long maintenance > > > > > > attempts 'crazy'; that may have intimidated some. I'm thinking of > > > > > > moving distro to one that provides longer term maintenance than my > > > > > > present one. Although CIP is a completely different ball game; I > > > > > > hope > > > > > > they succeed. > > > > > > > > > > It is not "crazy" it is "well documented". As someone who has been > > > > > doing this work for 20+ years now and sees all of the stable kernel > > > > > patches flow by, it's obvious that a distro that does not keep up with > > > > > them is insecure by design. > > > > > > > > If "newer is better" I'd agree. Sometimes "newer is actually worse". > > > > Some new features intended to improve things sometimes actually make > > > > things worse. > > > > > > That's not the issue here. > > > > > > Do you want to run a kernel with known security problems, or one with > > > "unknown potential problems." The latter is always the case, so please > > > don't pick the known-insecure one, that's just foolish. > > > > "security problems" are a dime a dozen, as they say. Speaking as a > > (thankfully former) downstream integrator, you'd have much more success > > if you stopped breaking backward compatibility with userspace all the > > damn time. Upgrading major kernel version is like rolling a dice, you > > never know what kind of extremely expensive and time consuming rabbit > > hole you'll be dragged into because the kernel plays fast and loose > > with its userspace interfaces, and each and every time there's a chance > > one might end up having to do major reworks to deal with it. > > We should never be breaking working userspace programs when upgrading > the kernel. If so, please report it to the regressions mailing list. > > Of course there's always some corner cases, but for the most part, this > should never happen. > > > So really it shouldn't be that surprising that users are averse to > > following the "latest is greatest" mantra from kernel.org, given how > > risky and expensive it is, and how little one gains in return. Rather > > than changing the world, what about changing your own processes first? > > A great starting point would be reverting backward incompatible changes > > regardless of who's affected, instead of doing that only if they affect > > the personal computer of a handful of maintainers (mainly Linus'), and > > shrugging reports away with "deal with it" in other cases. > > We should never be "shrugging" away reports like this. If you have > specific incidents that you wish to discuss, I will be glad to do so on > the regressions kernel mailing list. Otherwise this is way off-topic > for systemd-devel. > >From a systemd-relevant angle, this has happened before. Recently even: https://github.com/systemd/systemd/blob/8c70e8024ba8ff42c23f1a35b9e8fafddd5caa8d/NEWS#L2355-L2437 That means that from a reasonable systemd user perspective, we need to depend on Linux kernel 4.14 or higher to cross over that breakage. While it is true that the syscall interface is kept reasonably stable, almost everything else gets monkeyed with a lot, because a lot of kernel developers only consider the syscall interface a program interface. This is a problem because a *lot* of things are only accessible through other means (procfs, sysfs, uevents, etc.). Unfortunately, that means that in practice, the kernel interfaces that userspace *must* depend on break far more than anyone likes. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Do, 24.03.22 10:28, Luca Boccassi (bl...@debian.org) wrote: > > What I am trying to say is that it would actually help us a lot if > > we'd not just be able to take croupv2 for granted but to take a > > reasonably complete cgroupv2 for granted. > > > > Lennart > > > > -- > > Lennart Poettering, Berlin > > Yes, that does sound like worth exploring - our README doesn't document > it though, do we have a list of required controllers and when they were > introduced? So I'd argue cgroupsv2 was pretty useless before 4.15, since it lacked the cpu controller, which I'd argue is actually the one that matters most. hence, before 4.15 cgroupsv2 was an experiment, not something you could actually deploy. some other interesting milestones: * kcmp → 3.5 * renameat2 on all relevant file systems → 4.0 * pids controller in cgroupv1 → 4.3 * pids controller in cgroupv2 → 4.5 * cgroup namespaces → 4.6 * statx → 4.11 * pidfd → 5.3 This is just some quick search through man pages. There might be a lot of other stuff that would make sense for us to be able to rely on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 4:30 PM Michael Biebl wrote: > > As far as Debian is concerned, we do have > > 4.9.x in old old stable aka stretch > 4.19.x in old stable aka buster > 5.10.x in stable aka bullseye > 5.16.x in unstable/bookworm > > We do provide backports of current systemd versions for bullseye. I > also do care that users upgrading from bullseye to bookworm can > continue to use the old stable kernel, which would be 5.10.x > So all in all, not an issue from the Debian side, as this would mean > the baseline would be 5.10.x > > Obviously I can't speak for all our downstreams (like raspbian) or > individual users with their self-compiled kernels. > Which I guess is more common among Debian then e.g. Fedora users. > It's not *super-common* for Fedora users, but it *is* common in CentOS. There's an active backport of the latest systemd to CentOS Stream 8, which is a 4.18 kernel with backports of stuff across the board. So I would personally like for the latest systemd to work on CentOS/RHEL 8 still. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
As far as Debian is concerned, we do have 4.9.x in old old stable aka stretch 4.19.x in old stable aka buster 5.10.x in stable aka bullseye 5.16.x in unstable/bookworm We do provide backports of current systemd versions for bullseye. I also do care that users upgrading from bullseye to bookworm can continue to use the old stable kernel, which would be 5.10.x So all in all, not an issue from the Debian side, as this would mean the baseline would be 5.10.x Obviously I can't speak for all our downstreams (like raspbian) or individual users with their self-compiled kernels. Which I guess is more common among Debian then e.g. Fedora users. Regards, Michael Am Di., 22. März 2022 um 17:34 Uhr schrieb Zbigniew Jędrzejewski-Szmek : > > Hi all, > > we are considering dropping upstream support for kernel versions < 4.4. > Would this be a problem for anyone? (*). > > Zbyszek > > > (*) If you answer "yes", please substantiate why you are running new > systemd with such old kernels.
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Do, 24.03.22 14:05, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > Yes, that does sound like worth exploring - our README doesn't document > > it though, do we have a list of required controllers and when they were > > introduced? > > In the README: > Linux kernel >= 4.2 for unified cgroup hierarchy support > Linux kernel >= 4.10 for cgroup-bpf egress and ingress hooks > Linux kernel >= 4.15 for cgroup-bpf device hook > Linux kernel >= 4.17 for cgroup-bpf socket address hooks > > In this light, 4.19 is better than 4.4 or 4.9 ;) Well, the list is not complete. i.e. the "io" controller came late iirc. And killing and stuff too. would take some work to figure out which features of cgroupv2 we actually make us of, and then when they were added. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, 2022-03-24 at 14:05 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Mar 24, 2022 at 10:28:39AM +, Luca Boccassi wrote: > > On Thu, 2022-03-24 at 09:38 +0100, Lennart Poettering wrote: > > > On Mi, 23.03.22 11:28, Luca Boccassi (bl...@debian.org) wrote: > > > > > > > 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? > > > > > > Note that "cgroupv2 exists" and "cgroupv2 works well" are two distinct > > > things. Initially too few controllers supported cgroupv2 for cgroupv2 > > > to be actually useful. > > > > > > What I am trying to say is that it would actually help us a lot if > > > we'd not just be able to take croupv2 for granted but to take a > > > reasonably complete cgroupv2 for granted. > > > > Yes, that does sound like worth exploring - our README doesn't document > > it though, do we have a list of required controllers and when they were > > introduced? > > In the README: > Linux kernel >= 4.2 for unified cgroup hierarchy support > Linux kernel >= 4.10 for cgroup-bpf egress and ingress hooks > Linux kernel >= 4.15 for cgroup-bpf device hook > Linux kernel >= 4.17 for cgroup-bpf socket address hooks > > In this light, 4.19 is better than 4.4 or 4.9 ;) > > Zbyszek I saw that, but I'm pretty sure we need to keep all the bpf-related stuff optional regardless of that, forever. There's plenty of use cases that disable it entirely (in the sense, things shouldn't fall apart if we run on a non-bpf kernel and there are no bpf options configured in any unit). I have one of them. I think Lennart was referring to more 'core' controllers - maybe the cpuset is one that was added pretty late? But just going from memory here - it would be good to have a precise list. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 02:05:09PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Mar 24, 2022 at 10:28:39AM +, Luca Boccassi wrote: > > On Thu, 2022-03-24 at 09:38 +0100, Lennart Poettering wrote: > > > On Mi, 23.03.22 11:28, Luca Boccassi (bl...@debian.org) wrote: > > > > > > > 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? > > > > > > Note that "cgroupv2 exists" and "cgroupv2 works well" are two distinct > > > things. Initially too few controllers supported cgroupv2 for cgroupv2 > > > to be actually useful. > > > > > > What I am trying to say is that it would actually help us a lot if > > > we'd not just be able to take croupv2 for granted but to take a > > > reasonably complete cgroupv2 for granted. > > > > Yes, that does sound like worth exploring - our README doesn't document > > it though, do we have a list of required controllers and when they were > > introduced? > > In the README: > Linux kernel >= 4.2 for unified cgroup hierarchy support > Linux kernel >= 4.10 for cgroup-bpf egress and ingress hooks > Linux kernel >= 4.15 for cgroup-bpf device hook > Linux kernel >= 4.17 for cgroup-bpf socket address hooks > > In this light, 4.19 is better than 4.4 or 4.9 ;) Then move to 4.19. I strongly doubt that any distro that is using older kernels would ever be willing to update systemd. thanks, greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 10:28:39AM +, Luca Boccassi wrote: > On Thu, 2022-03-24 at 09:38 +0100, Lennart Poettering wrote: > > On Mi, 23.03.22 11:28, Luca Boccassi (bl...@debian.org) wrote: > > > > > 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? > > > > Note that "cgroupv2 exists" and "cgroupv2 works well" are two distinct > > things. Initially too few controllers supported cgroupv2 for cgroupv2 > > to be actually useful. > > > > What I am trying to say is that it would actually help us a lot if > > we'd not just be able to take croupv2 for granted but to take a > > reasonably complete cgroupv2 for granted. > > Yes, that does sound like worth exploring - our README doesn't document > it though, do we have a list of required controllers and when they were > introduced? In the README: Linux kernel >= 4.2 for unified cgroup hierarchy support Linux kernel >= 4.10 for cgroup-bpf egress and ingress hooks Linux kernel >= 4.15 for cgroup-bpf device hook Linux kernel >= 4.17 for cgroup-bpf socket address hooks In this light, 4.19 is better than 4.4 or 4.9 ;) Zbyszek
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 10:23:21AM +, Luca Boccassi wrote: > On Thu, 2022-03-24 at 09:45 +0100, Greg Kroah-Hartman wrote: > > On Thu, Mar 24, 2022 at 09:33:50AM +0100, Ulrich Windl wrote: > > > > > > Greg KH schrieb am 24.03.2022 um 08:12 > > > > > > in > > > Nachricht : > > > > On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: > > > > > FWIW, I think Greg was a bit too outspoken calling long maintenance > > > > > attempts 'crazy'; that may have intimidated some. I'm thinking of > > > > > moving distro to one that provides longer term maintenance than my > > > > > present one. Although CIP is a completely different ball game; I hope > > > > > they succeed. > > > > > > > > It is not "crazy" it is "well documented". As someone who has been > > > > doing this work for 20+ years now and sees all of the stable kernel > > > > patches flow by, it's obvious that a distro that does not keep up with > > > > them is insecure by design. > > > > > > If "newer is better" I'd agree. Sometimes "newer is actually worse". > > > Some new features intended to improve things sometimes actually make > > > things worse. > > > > That's not the issue here. > > > > Do you want to run a kernel with known security problems, or one with > > "unknown potential problems." The latter is always the case, so please > > don't pick the known-insecure one, that's just foolish. > > "security problems" are a dime a dozen, as they say. Speaking as a > (thankfully former) downstream integrator, you'd have much more success > if you stopped breaking backward compatibility with userspace all the > damn time. Upgrading major kernel version is like rolling a dice, you > never know what kind of extremely expensive and time consuming rabbit > hole you'll be dragged into because the kernel plays fast and loose > with its userspace interfaces, and each and every time there's a chance > one might end up having to do major reworks to deal with it. We should never be breaking working userspace programs when upgrading the kernel. If so, please report it to the regressions mailing list. Of course there's always some corner cases, but for the most part, this should never happen. > So really it shouldn't be that surprising that users are averse to > following the "latest is greatest" mantra from kernel.org, given how > risky and expensive it is, and how little one gains in return. Rather > than changing the world, what about changing your own processes first? > A great starting point would be reverting backward incompatible changes > regardless of who's affected, instead of doing that only if they affect > the personal computer of a handful of maintainers (mainly Linus'), and > shrugging reports away with "deal with it" in other cases. We should never be "shrugging" away reports like this. If you have specific incidents that you wish to discuss, I will be glad to do so on the regressions kernel mailing list. Otherwise this is way off-topic for systemd-devel. thanks, greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, 2022-03-24 at 09:38 +0100, Lennart Poettering wrote: > On Mi, 23.03.22 11:28, Luca Boccassi (bl...@debian.org) wrote: > > > 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? > > Note that "cgroupv2 exists" and "cgroupv2 works well" are two distinct > things. Initially too few controllers supported cgroupv2 for cgroupv2 > to be actually useful. > > What I am trying to say is that it would actually help us a lot if > we'd not just be able to take croupv2 for granted but to take a > reasonably complete cgroupv2 for granted. > > Lennart > > -- > Lennart Poettering, Berlin Yes, that does sound like worth exploring - our README doesn't document it though, do we have a list of required controllers and when they were introduced? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
On Thu, 2022-03-24 at 09:45 +0100, Greg Kroah-Hartman wrote: > On Thu, Mar 24, 2022 at 09:33:50AM +0100, Ulrich Windl wrote: > > > > > Greg KH schrieb am 24.03.2022 um 08:12 in > > Nachricht : > > > On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: > > > > FWIW, I think Greg was a bit too outspoken calling long maintenance > > > > attempts 'crazy'; that may have intimidated some. I'm thinking of > > > > moving distro to one that provides longer term maintenance than my > > > > present one. Although CIP is a completely different ball game; I hope > > > > they succeed. > > > > > > It is not "crazy" it is "well documented". As someone who has been > > > doing this work for 20+ years now and sees all of the stable kernel > > > patches flow by, it's obvious that a distro that does not keep up with > > > them is insecure by design. > > > > If "newer is better" I'd agree. Sometimes "newer is actually worse". > > Some new features intended to improve things sometimes actually make things > > worse. > > That's not the issue here. > > Do you want to run a kernel with known security problems, or one with > "unknown potential problems." The latter is always the case, so please > don't pick the known-insecure one, that's just foolish. "security problems" are a dime a dozen, as they say. Speaking as a (thankfully former) downstream integrator, you'd have much more success if you stopped breaking backward compatibility with userspace all the damn time. Upgrading major kernel version is like rolling a dice, you never know what kind of extremely expensive and time consuming rabbit hole you'll be dragged into because the kernel plays fast and loose with its userspace interfaces, and each and every time there's a chance one might end up having to do major reworks to deal with it. So really it shouldn't be that surprising that users are averse to following the "latest is greatest" mantra from kernel.org, given how risky and expensive it is, and how little one gains in return. Rather than changing the world, what about changing your own processes first? A great starting point would be reverting backward incompatible changes regardless of who's affected, instead of doing that only if they affect the personal computer of a handful of maintainers (mainly Linus'), and shrugging reports away with "deal with it" in other cases. Just my 2c. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 08:08:31AM +0100, Greg KH wrote: > On Wed, Mar 23, 2022 at 10:11:36PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > > > 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. > > Why not email them and ask? https://gitlab.com/cip-project/cip-core/cip-pkglist/-/issues/6 Zbyszek
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 09:33:50AM +0100, Ulrich Windl wrote: > >>> Greg KH schrieb am 24.03.2022 um 08:12 in > Nachricht : > > On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: > >> FWIW, I think Greg was a bit too outspoken calling long maintenance > >> attempts 'crazy'; that may have intimidated some. I'm thinking of > >> moving distro to one that provides longer term maintenance than my > >> present one. Although CIP is a completely different ball game; I hope > >> they succeed. > > > > It is not "crazy" it is "well documented". As someone who has been > > doing this work for 20+ years now and sees all of the stable kernel > > patches flow by, it's obvious that a distro that does not keep up with > > them is insecure by design. > > If "newer is better" I'd agree. Sometimes "newer is actually worse". > Some new features intended to improve things sometimes actually make things > worse. That's not the issue here. Do you want to run a kernel with known security problems, or one with "unknown potential problems." The latter is always the case, so please don't pick the known-insecure one, that's just foolish. greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Mi, 23.03.22 11:28, Luca Boccassi (bl...@debian.org) wrote: > 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? Note that "cgroupv2 exists" and "cgroupv2 works well" are two distinct things. Initially too few controllers supported cgroupv2 for cgroupv2 to be actually useful. What I am trying to say is that it would actually help us a lot if we'd not just be able to take croupv2 for granted but to take a reasonably complete cgroupv2 for granted. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
>>> Greg KH schrieb am 24.03.2022 um 08:12 in Nachricht : > On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: >> FWIW, I think Greg was a bit too outspoken calling long maintenance >> attempts 'crazy'; that may have intimidated some. I'm thinking of >> moving distro to one that provides longer term maintenance than my >> present one. Although CIP is a completely different ball game; I hope >> they succeed. > > It is not "crazy" it is "well documented". As someone who has been > doing this work for 20+ years now and sees all of the stable kernel > patches flow by, it's obvious that a distro that does not keep up with > them is insecure by design. If "newer is better" I'd agree. Sometimes "newer is actually worse". Some new features intended to improve things sometimes actually make things worse. Regards, Ulrich
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: > FWIW, I think Greg was a bit too outspoken calling long maintenance > attempts 'crazy'; that may have intimidated some. I'm thinking of > moving distro to one that provides longer term maintenance than my > present one. Although CIP is a completely different ball game; I hope > they succeed. It is not "crazy" it is "well documented". As someone who has been doing this work for 20+ years now and sees all of the stable kernel patches flow by, it's obvious that a distro that does not keep up with them is insecure by design. To not think otherwise is crazy and negligent. I'm serious, and have the numbers and research to back it up. I would love for someone to be able to prove me wrong as I wish this wasn't the case. So please push back on any distro that goes outside of the kernel.org support window with requests and contract assurances on how they can ensure that they keep up with all of the needed security fixes over time. If you are paying for this, you deserve that information. If you are not paying for it, you get what you pay for :( Sorry this is getting off-topic here for systemd-devel, but it's something that I have been trying to get across to the Linux community for a very long time now. thanks, greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 10:11:36PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > > 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. Why not email them and ask? thanks, greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 03:58:22PM +, Luca Boccassi wrote: > On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote: > > On Wed, Mar 23, 2022 at 11:28:29AM +, 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. I am trying to _change_ how the world works, because the way it currently works for some companies/distros is totally broken and insecure. To just ignore it is to give up. > 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. But if kernel.org tells them that what they are using is insecure, they should push back on their distro and vendor to have them prove that this is not true. So far I have never seen a distro or vendor that uses older kernels without an insecure kernel. And I've audited hundreds of them. > 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. Those people are not using new versions of systemd, are they? And if they are, they need to get $crappy_arm_vendor to do the work for them as they PAID for that support and work already. thanks, greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, 23 Mar 2022 22:26:15 +0100 Michael Biebl wrote: > Am Mi., 23. März 2022 um 22:11 Uhr schrieb Zbigniew Jędrzejewski-Szmek > : > > > 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. > > That's laudable but keep in mind that users typically don't follow > systemd-devel actively. I'm pretty sure we don't even have > *maintainers* of embedded Linux following this mailing list. I'm just a user and I follow this list. That is to say, it doesn't matter what typical users or maintainers do, it's enough if just one relevant person is following. It would be nice though, if there are any such people, if they would speak up and offer their opinion or say that they are going to take it to whichever manager/committee they need to. FWIW, I think Greg was a bit too outspoken calling long maintenance attempts 'crazy'; that may have intimidated some. I'm thinking of moving distro to one that provides longer term maintenance than my present one. Although CIP is a completely different ball game; I hope they succeed. Cheers, Dave
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
Am Mi., 23. März 2022 um 22:11 Uhr schrieb Zbigniew Jędrzejewski-Szmek : > 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. That's laudable but keep in mind that users typically don't follow systemd-devel actively. I'm pretty sure we don't even have *maintainers* of embedded Linux following this mailing list.
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 03:58:22PM +, Luca Boccassi wrote: > On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote: > > On Wed, Mar 23, 2022 at 11:28:29AM +, 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
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote: > On Wed, Mar 23, 2022 at 11:28:29AM +, 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 signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Wed, Mar 23, 2022 at 11:28:29AM +, 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
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
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 signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
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
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
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. > 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" :) thanks, greg k-h
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
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]. In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9, and after that Buster has 4.19. Of course we'd like to move to 4.19, but we don't want to disrupt distros that use older kernels. Is ≤4.19 really unused? [1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start Zbyszek
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
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? thanks, greg k-h
[systemd-devel] version bump of minimal kernel version supported by systemd?
Hi all, we are considering dropping upstream support for kernel versions < 4.4. Would this be a problem for anyone? (*). Zbyszek (*) If you answer "yes", please substantiate why you are running new systemd with such old kernels.
