A bunch of old networking infrastructure and drivers after a short discussion phase were now removed for #Linux 7.1.
-
RE: https://hachyderm.io/@kernellogger/116454517064991950
A bunch of old networking infrastructure and drivers after a short discussion phase were now removed for #Linux 7.1. Among them:
* ISDN subsystem and Bluetooth CMTP
* ax25 and amateur radio (hamradio)
* CAIF NETWORK LAYER
* used ATM protocols and legacy ATM device drivers
* several drivers, among them the one for 3com 3c509 chipsFor details see: https://git.kernel.org/torvalds/c/64edfa65062dc4509ba75978116b2f6d392346f5
In case you actually use anything in production (see the post below), speak up, as then the removal might be reverted, as Linus clarified in https://lore.kernel.org/all/CAHk-%3DwimzLyMALBZmQUDGs%3DX0uJhnLhpsQJ1c77%3DBMwhx4GT4A@mail.gmail.com/ – to quote:
"I think we can easily resurrect individual drivers if there are actual users."
-
RE: https://hachyderm.io/@kernellogger/116454517064991950
A bunch of old networking infrastructure and drivers after a short discussion phase were now removed for #Linux 7.1. Among them:
* ISDN subsystem and Bluetooth CMTP
* ax25 and amateur radio (hamradio)
* CAIF NETWORK LAYER
* used ATM protocols and legacy ATM device drivers
* several drivers, among them the one for 3com 3c509 chipsFor details see: https://git.kernel.org/torvalds/c/64edfa65062dc4509ba75978116b2f6d392346f5
In case you actually use anything in production (see the post below), speak up, as then the removal might be reverted, as Linus clarified in https://lore.kernel.org/all/CAHk-%3DwimzLyMALBZmQUDGs%3DX0uJhnLhpsQJ1c77%3DBMwhx4GT4A@mail.gmail.com/ – to quote:
"I think we can easily resurrect individual drivers if there are actual users."
@kernellogger 3c509? Whoa. Used those in my first router box at home. That's probably 25 years ago now.
-
RE: https://hachyderm.io/@kernellogger/116454517064991950
A bunch of old networking infrastructure and drivers after a short discussion phase were now removed for #Linux 7.1. Among them:
* ISDN subsystem and Bluetooth CMTP
* ax25 and amateur radio (hamradio)
* CAIF NETWORK LAYER
* used ATM protocols and legacy ATM device drivers
* several drivers, among them the one for 3com 3c509 chipsFor details see: https://git.kernel.org/torvalds/c/64edfa65062dc4509ba75978116b2f6d392346f5
In case you actually use anything in production (see the post below), speak up, as then the removal might be reverted, as Linus clarified in https://lore.kernel.org/all/CAHk-%3DwimzLyMALBZmQUDGs%3DX0uJhnLhpsQJ1c77%3DBMwhx4GT4A@mail.gmail.com/ – to quote:
"I think we can easily resurrect individual drivers if there are actual users."
@kernellogger One thing that bothers me about this (not that I think it's anyone's fault, or that I have an easy solution) is the people that have a genuine need for these old drivers (like the guy who spoke up about the 905), but that _don't_ follow LKML closely. They will likely only find out about this a year or more later when that kernel makes it to their distro, and then they are SOL and will have to ask someone to maintain the patch that keeps the driver around, likely for lots of cash.
-
@kernellogger One thing that bothers me about this (not that I think it's anyone's fault, or that I have an easy solution) is the people that have a genuine need for these old drivers (like the guy who spoke up about the 905), but that _don't_ follow LKML closely. They will likely only find out about this a year or more later when that kernel makes it to their distro, and then they are SOL and will have to ask someone to maintain the patch that keeps the driver around, likely for lots of cash.
@klausman what bothers me are people that expect 10+ or 15+ year old hardware to continue to work when jumping from one longterm kernel to the next without doing a dime to help with that in return for what they get for free.
Because that shows that the #Linux #kernel community, or maybe the whole FLOSS ecosystem, is doing a bad job at communicating that developers and testers need to invest at least time and maybe money to ensure things continue to work.
Which is why at some point things, at least for the #LinuxKernel with its "no regressions" policy, boil down to: "Unless somebody tests regularly (e.g., at least each new mainline version, better each new -rc1), things you care about might get broken and/or removed before it becomes hard or impossible to fix that".
If a hardware is very widespread, there is a decent chance that somebody else will do that testing[1]; but over time you might need to become that "somebody" to prevent a unhappy outcome for yourself and others.
[1] but hardware is tricky and has many warts that show up only in special environments. Maybe yours is one of those, so you might want to help with testing nevertheless. Which is a good way to give back to FLOSS.
-
RE: https://hachyderm.io/@kernellogger/116454517064991950
A bunch of old networking infrastructure and drivers after a short discussion phase were now removed for #Linux 7.1. Among them:
* ISDN subsystem and Bluetooth CMTP
* ax25 and amateur radio (hamradio)
* CAIF NETWORK LAYER
* used ATM protocols and legacy ATM device drivers
* several drivers, among them the one for 3com 3c509 chipsFor details see: https://git.kernel.org/torvalds/c/64edfa65062dc4509ba75978116b2f6d392346f5
In case you actually use anything in production (see the post below), speak up, as then the removal might be reverted, as Linus clarified in https://lore.kernel.org/all/CAHk-%3DwimzLyMALBZmQUDGs%3DX0uJhnLhpsQJ1c77%3DBMwhx4GT4A@mail.gmail.com/ – to quote:
"I think we can easily resurrect individual drivers if there are actual users."
@kernellogger Heh .... ok ISDN and the 3c509 stuff is sad.. truly..
But at ax25 and amateur/ham-radio stuff, it may worth to wait a bit for their removal, as HAMs just recently start to discover linux for their needs.... Usually their stuff is always windows based because everyone has windows..
But they get tired of microslop too .... so still having native ax25 and others ham radio related stuff might be a good thing ... at least for a while still.
-
@klausman what bothers me are people that expect 10+ or 15+ year old hardware to continue to work when jumping from one longterm kernel to the next without doing a dime to help with that in return for what they get for free.
Because that shows that the #Linux #kernel community, or maybe the whole FLOSS ecosystem, is doing a bad job at communicating that developers and testers need to invest at least time and maybe money to ensure things continue to work.
Which is why at some point things, at least for the #LinuxKernel with its "no regressions" policy, boil down to: "Unless somebody tests regularly (e.g., at least each new mainline version, better each new -rc1), things you care about might get broken and/or removed before it becomes hard or impossible to fix that".
If a hardware is very widespread, there is a decent chance that somebody else will do that testing[1]; but over time you might need to become that "somebody" to prevent a unhappy outcome for yourself and others.
[1] but hardware is tricky and has many warts that show up only in special environments. Maybe yours is one of those, so you might want to help with testing nevertheless. Which is a good way to give back to FLOSS.
@kernellogger What bothers me is not "pls provide free support forever!", but rather visibility. Even if you constrain it to "people who make money running Linux on 15yo hardware they inherited", I don't think it's very reasonable to assume they subscribe to the firehose that is LKML. Running every .0 I can see in such a context, but I fear even then it's quite an uphill battle to at that point convince the kernel devs to undo a driver removal. 1/2
-
@kernellogger What bothers me is not "pls provide free support forever!", but rather visibility. Even if you constrain it to "people who make money running Linux on 15yo hardware they inherited", I don't think it's very reasonable to assume they subscribe to the firehose that is LKML. Running every .0 I can see in such a context, but I fear even then it's quite an uphill battle to at that point convince the kernel devs to undo a driver removal. 1/2
@kernellogger Worse, it hurts not just people who really should have the budget to upgrade their hardware and are just lazy --- because they will just run old kernels and happily be vulnerable.
It also hurts those that are trying to not create e-waste when there is no reason to do so. One can argue that newer CPUs are more power efficient etc and thus upgrading is a net positive. I doubt that is true for most peripherals and things like NICs.
As I said, it sucks for everyone, I realize that.
-
@kernellogger What bothers me is not "pls provide free support forever!", but rather visibility. Even if you constrain it to "people who make money running Linux on 15yo hardware they inherited", I don't think it's very reasonable to assume they subscribe to the firehose that is LKML. Running every .0 I can see in such a context, but I fear even then it's quite an uphill battle to at that point convince the kernel devs to undo a driver removal. 1/2
@klausman nobody asked "to subscribe to the firehose that is LKML", so sorry, that is a strawman.
"quite an uphill battle": you have to make your case, yes -- and it can be an uphill battle occasionally *if* that can cause huge security problems for the kernel as a whole, as that it become a judgement call. But several removals were reverted over time, so from my point of view "quite an uphill battle" does not describe the situations adequately.
-
@kernellogger Worse, it hurts not just people who really should have the budget to upgrade their hardware and are just lazy --- because they will just run old kernels and happily be vulnerable.
It also hurts those that are trying to not create e-waste when there is no reason to do so. One can argue that newer CPUs are more power efficient etc and thus upgrading is a net positive. I doubt that is true for most peripherals and things like NICs.
As I said, it sucks for everyone, I realize that.
@klausman I see your point, but still: testing new Linux mainline releases is not that hard. If your distro makes it hard then it's the distro that is the problem.
-
@klausman nobody asked "to subscribe to the firehose that is LKML", so sorry, that is a strawman.
"quite an uphill battle": you have to make your case, yes -- and it can be an uphill battle occasionally *if* that can cause huge security problems for the kernel as a whole, as that it become a judgement call. But several removals were reverted over time, so from my point of view "quite an uphill battle" does not describe the situations adequately.
@kernellogger My point about the firehose was that even when testing every .0, it would be the only way for people who use these drivers to chime in before the removal of a driver, and thus potentially avoiding a) work+churn and b) now having an arbitrary series of kernels that won't work for them. IWBNI there was an "early warning system" for driver removals --- though that may invite bike shedding.
I would also argue that it's harder to get a driver back than to not have it removed.
-
R relay@relay.infosec.exchange shared this topic
