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 chips

For 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."

#LinuxKernel #kernel

@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.

@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.

@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.

@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.

@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.

@klausman

a "git revert cafecafe" is not much work+churn and such reverts (aka reapplying a driver) have been backported to stable series, so the problem can quickly vanish.

And harder: yes, but from what I've seen not much harder in most cases.

Overall just switching to the latest stable series within two or three weeks after a new mainline release (like Arch, Tumbleweed and Fedora do) should do the trick. Testing mainline -rc1 will be even better, but most likely it will work without that.

@kernellogger haven't checked, but can any of those thinks be used as part of the lib-target? That might be an okayish solution to keep networking code usable without needing to keep it in the Kernel.
I am clearly pro cleanup.
Things that nobody frequently tests and that are defacto unmaintained create a false sense of security and are better removed from the Kernel.

@mxk you mean via https://github.com/lkl? No idea, but I doubt it.

And I disagree with you last statement: unmaintained code is not that bad, as long as it's not a maintenance burden or a obvious security risk, especially in for people that don't even use it. Which I think it was round about fine that that stuff was kept around until now.

Of course where to draw the line is not easy and often needs to be decided on a case by case basis [which is why debating this further here might not be worth it, as that is hard in writing without concrete cases]

@kernellogger I'd like some clarification over whether there are outstanding security reports against this pile; i.e. what's the situation on older stable kernels which still have these?

@penguin42 well, not sure if those are real "security reports" or just "reports about possible security vulnerabilities and there is nobody that cares enough to check each of them".

But overall that is a good question.

Wonder if things might just stay as they are now until some good or bad guy looks into those reports and finds something real.

@klausman @kernellogger There is no free lunch, so people who have "genuine need" of particular drivers need to pay with their testing of new kernel releases (LKML does not matter here - no one needs to read it). This applies to individual users or companies using some very old LTS. If they ever tested only their old LTS (imagine v4.4 with stunning 300 stable releases for 6 years of official support!), never moved their kernel for their products to any newer LTS, not even imagining testing newer standard release, what do they expect?

That some maintainers will do the work for them for free?

Free Software is free as in freedom of usage, not free of the effort. I think many forgot that and assume Linux comes for them for free as in free beer, thus they have no obligations and can be just consumers of it.

@krzk @kernellogger @klausman While people should not expect free lunch, I think this is too simple. The cost depends on other upstream activities. For example, if code is changed because there is a 0.5% gain for some hyperscaler, this means people who were already happy about how things are need to test. One can argue that who pays the main contributors can decide, but one should acknowledge that Linux traditionally also served other communities which may not be able to keep up.

@krzk @kernellogger @klausman Or - maybe exaggerated but for sake of argument - if Linux now serves mainly the role of american big tech value chain, and stuff which only interests hobbiests or fringe communities is removed as soon as some AI may think there is a bug, and the the argument is that this is fine because big tech pays the core developers, then maybe the rest of us traditional free software enthusiasts should understand that it is time to move elsewhere.

@uecker @kernellogger @klausman Your post makes impression that paying main contributor somehow causes that contributor to do something else, than would be good for community? That's not the case.

Every contributor pulls the project where they want. And they can. Big corpo usually does not stop them. Contributors who are paid as part of their job, pull towards whatever they need to because for example manager told them.

Contributors who are hobbyists, with whom I deal a lot, pull to solve their hobbyist needs. No problem here...

No one (or not enough) was pulling ISDN or other drivers, so these are going away. And this is what entire post is about.

Somehow people expect someone will do the work for free (this pulling of the project) for them. Many people do work for free, because of their choice/needs, but EXPECTING someone to work for free is unacceptable.

@uecker @kernellogger @klausman Each of these people having "genuine" needs of removed drivers could step up and help. Still can, like it happened with NFC which I left and was about to be removed, if I did not poke David. If these users do not step up, they have no rights to complain, because one cannot expect someone else doing work for free.

@kernellogger @klausman @uecker And the license governing Linux kernel kind of emphasizes this:

“This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.”

Which also means without warranty of support. We only HOPE it will be useful.

@krzk @kernellogger @klausman As i said, i agree in principle, but i think this is a bit too simple to only look at this from this perspective. The question is how easy / open it is for people to contribute nowadays. Following, using, and contributing to free software for a long time, this got much more effort for many projects, especially for newcomers. And I do not want to end up where the "entrance card" is being able to pay a kernel developer.

@uecker @kernellogger @klausman There are no barriers to contribute, no payments needed, except one's time. Plenty of guides, plenty of resources, one just have to devote their time.

The entire and only point is here that simple: no one wanted to pay to maintain these drivers and no one wanted to devote enough of their own time to do that (except of course of netdev maintainers who have enough on their plate).

@krzk @kernellogger @klausman The question is how much time is necessary.

@uecker @kernellogger @klausman There was no such question when concerns of removal of the drivers were raised. Complains about dropped drivers did not come with "I wanted to devote my time, but I was rejected". No one was rejected, because no one volunteered to handle all this.

@krzk @uecker As you keep @-adding me in your discussion: my only point was that _earlier warning_ would be nice. Even running all .0 kernels can be a bit late as by then, the decisison has been made. It's not _impossible_ to bring a driver back, but I feel a lot of work and time could be saved if people had a way to be informed of driver removals as the relevant discussions happen, then they can chime in. Given the distributed discussion of kernel matters, this currently is not very feasible.

@krzk @kernellogger @klausman People affected are most like not even seeing this discussion on the kernel list.
I am just generally concerned about the development that "free software" is now something shaped by north-american tech's interests, and I push back against the idea that everybody who has other interests should be able to afford to vest a substantial amount of time or money. But if this is not the case here and truly nobody cares, I am not at against dropping the drivers.

@uecker so we made circle... You repeated earlier thought. There's no shaping by American tech interests in this matter. Just American tech does not pay for these drivers and no one else paid, either. Paid as with money or their time. It's not the American interests who decided to drop these drivers.
And it's really not that difficult to maintain all of removed stuff. One doesn't have to be even skilled... I was doing it, e.g. NFC. It requires only one, the most scarce resource: time.

@krzk You did not address my early point, which was that if development is mainly driven by specific parts of the industry, then it makes it more costly for others to contribute (in time or money). This is why I think the "you should just contribute" argument is too simplistic. But if you are saying it is still very easy to step up for volunteers with limited time and take over maintenance of a driver, then I am happy to concede that this does not apply to the kernel.