Linux 6.4 Slated To Start Removing Old, Unused & Unmaintained PCMCIA Drivers

[aviallon]

It is not like Linux kernel 6.3 would not be erased from the internet is it? If some old cruft is removed it is "just" a matter of downgrading to a older Linux kernel release / distro. That being said I do actually agree with you , removing things just for the sake of removing it is evil. The problem here seems to be that the thing they remove does not work properly in the first place and since they are unmaintained they are not going to in the near future either...

I frequently had freezes on laptops having PCMCIA slots if I didn't blacklist PCMCIA drivers.
So yeah, they are VERY broken.

[rogerx]

Funny as hell. Utterly non-sense follow-up posts. Also, completely clueless with the rational for needing older hardware for converting old analog media materials to digital, assuming nowadays hardware is much better.

If a user cannot run a recent Linux kernel on older hardware or a Linux kernel with the said drivers, and continue needing to use the older hardware; then they must use some old saved binary only Linux distribution or revert to using Windows XP. I would say, much easier just using Windows XP for said tasks.

I must say, it is far easier grabbing an old version of Windows XP rather than trying to find an old Linux binary only distribution. I had no problems running recent Linux kernels on the old 2001 Pentium 3 Dell Inspiron 8100, along with using Gentoo, a source based distribution. Just need to know what you're doing, and perform tasks within reason. However, then Rust language came along in year of ~2019 and cut Pentium 3 support, from there, had to put the thing in storage due to everything starting to automatically depend on Rust language. Early versions of PCMCIA did have bugs, as with everything, but was stable, likely since ~2005/2010 on the Dell Inspiron.

I tend to agree, non-developed/non-maintained drivers should be somehow set aside, but stripping and trashing seems quite odd. Somehow having out-of-tree drivers would seem to solve this; but then out-of-tree driver packages tend to break due to recent kernel versions breaking typical build protocols. In other words, the kernel build system sometimes, from past experience, would not be backwards portable.

[Vistaus]

But but but… 90% of Phoronix users use these drivers still.

[mifritscher]

rogerx: debian has an archive. And as I said, PCMCIA = the old 16 bit isa-style port. Not the 32 bit cardbus, which are you using on a Pentium 3 Laptop. And there are plans to migrate the cardbus in the pci hotplug code - and this code is e.g. used in VMs.

Btw, even 2008 laptops had cardbus slots, so yes, it is far to early to kill cardbus. But cardbus was quite stable at the beginning, and is a quite "clean" standard without peculiarities.

[LinuxID10T]

Funny as hell. Utterly non-sense follow-up posts. Also, completely clueless with the rational for needing older hardware for converting old analog media materials to digital, assuming nowadays hardware is much better.

Unfortunately, modern hardware is generally far inferior. Like, not even close. The best scanning hardware for many applications uses SCSI or FireWire…

[Weasel]

Actually they could be hurting people and they dont even know it! If these drivers are getting compiled in, or even compiled as modules they do get to interface with the kernel. Sure a module driver that is "unloaded" can just sit there and occupy a couple of mb of space doing nothing, but if it gets loaded and its no longer being maintained that's a very big issue.

This is full of shit. It's pathetic how many likes you got for complete bullshit misinformation, proving how cringe clowns people are on this board.

If a kernel module is not loaded then it is NOT loaded. Doesn't matter if it "interfaces" with the kernel or not (all of them do, so that makes zero sense to begin with). It sits on your disk but isn't loaded in memory (or rather, memory mapped, so even loading it isn't so bad or a waste of resources, if it sits idle).

God forbid you lose a few kilobytes of disk space! The horror!!!

Real reason most of these get removed is that, since the kernel interface isn't stable (in the source code), they are simply lazy and don't want to keep updating the interface of such old drivers so that they compile successfully in the first place. The truth is usually far simpler than rose tinted glasses view you have.

[zexelon]

This is full of shit. It's pathetic how many likes you got for complete bullshit misinformation, proving how cringe clowns people are on this board.

If a kernel module is not loaded then it is NOT loaded. Doesn't matter if it "interfaces" with the kernel or not (all of them do, so that makes zero sense to begin with). It sits on your disk but isn't loaded in memory (or rather, memory mapped, so even loading it isn't so bad or a waste of resources, if it sits idle).

God forbid you lose a few kilobytes of disk space! The horror!!!

Real reason most of these get removed is that, since the kernel interface isn't stable (in the source code), they are simply lazy and don't want to keep updating the interface of such old drivers so that they compile successfully in the first place. The truth is usually far simpler than rose tinted glasses view you have.

It is nice that you have found a "safe place" to be needlessly confrontational.

Try maintaining code first. This is ~20 yr old code for devices and even standards that have not been in play for well over a decade. Yes an unloaded module has no direct affect on a running kernel, however there re so many edge cases in software dev called "side effects" that cannot be foreseen or in many cases even tested for. It is always better to reduce a code base than to expand it.

If this is such a personal affront to your beliefs then go maintain the drivers, you are free to do so. If that is not some burning desire, then let them go. If you cant maintain them, yet you have a need for them, then use the legacy kernel... its not like Linus is deleting all the archived kernels!

Heck I have an SBC around here that requires a 2.4 era kernel! Its not like I will be screaming to get it into a 6.4 version!

[stormcrow]

I hope you mean "selling them".

No, I meant what I said. Unless a known LKD or BSD kernel developer wants them before I do, I'll eventually toss them. Individual hardware components that old are rarely useful to anyone. Selling them so they can sit on some retro enthusiast closet shelf for another 15 years won't help anyone, either. That said, I may put out a note to the OpenBSD (or NetBSD) projects before I toss them, see if someone there wants them (free to a good home). The amount of functional older drivers seem to be higher in OpenBSD and NetBSD than in Linux where driver projects are started then abandoned with unfortunate regularity only to break a few releases later. If anyone would want such ancient PCMCIA NICs and modems for actual use, it'll be the BSD people.

[rogerx]

rogerx: debian has an archive. And as I said, PCMCIA = the old 16 bit isa-style port. Not the 32 bit cardbus, which are you using on a Pentium 3 Laptop. And there are plans to migrate the cardbus in the pci hotplug code - and this code is e.g. used in VMs.

Btw, even 2008 laptops had cardbus slots, so yes, it is far to early to kill cardbus. But cardbus was quite stable at the beginning, and is a quite "clean" standard without peculiarities.

The Dell Inspiron 8100 has a PCMCIA slot(s), both 16 and 32 bit.

After sleeping on this, and similar such inspiring news articles posted by Phoronix in the past, realizing this kernel code removal should likely have a better policy for driver removal, supporting those wanting to use the older hardware.

I'm thinking something as simple as maintaining a single easily accessible/published listing of when certain pieces of consumer hardware has been dropped/removed from the kernel, so a consumer can easily look-up the last supported kernel or known stable kernel for their particular hardware. This policy could go so far as stating support for hardware for known working drivers for ten or so years. Currently, think Microsoft and all the people just buying newer hardware, would likely endorse the ten year policy, until the policy became 20 or 30 years.

The main point for my posts, many have spent money on the hardware and many have spent time submitting code, ridiculous to just simply delete code, or remove haphazardly.

1) maintaining a separate easily accessible hardware driver list removal date for consumers.

2) either pushing the non-maintained code to a make config directory, such as "non-maintained drivers", preserving the drivers for others to easily build with the kernel, but statically disabled, separate from the usual build all commands.

3) start pushing the code into separate trees? I see this as a last ditch lazy attempt at saving code. Think once code is submitted, the code should be maintained by kernel developers indefinitely. Unless they want to get like Rust developers, and simply cutting support to older hardware based on what they want to do.

Well, just some ideas. Just don't hold me to this post. Just throwing out some ideas, likely already known.

[rogerx]

Unfortunately, modern hardware is generally far inferior. Like, not even close. The best scanning hardware for many applications uses SCSI or FireWire…

No, really. Newer hardware is lousey at some tasks than older hardware! Not joking.