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

[Jakobson]

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.

No need for that. The driver code remains in Linux git repository forever.

[mifritscher]

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

Yes, but I don't think that you put it 16 bit cards, so you don't use the "classic" PCMCIA mode, but the cardbus mode.

[NathanG]

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

That would be useful if anyone wants to step up.

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.

Who would pay these kernel developers to support a code base used by maybe just hundreds of people and very unlikely any revenue?

[erniv2]

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

Not to mention that scsi was a enterprise solutioun every other system used ide, and firewire was dead to begin with FireWire – Wikipedia was for some strange cameras that used it i think i had a motherboard with a firewire port sometime but it was never used and even the driver support in windows xp was well it was detected in the device manager.

And PC Card – Wikipedia is so old do you realy still use some old mobile card for a laptop ? i doubt that, i even doubt that any carrier still offers that kind of mobile service to begin with.

Oh and why is scsi superior to other standards ?

Scsi was the pro dude thing in the 90 it was serial and ide was parralel, and then came sata, serial transfers and sas and whatever.

Actually Pata(ide) was allready superior to scsi back then you only had to terminat 1 drive, 1 was master 2 was slave and you only could have 2 devcies on one slot.

Scsi allowed you like 7 drives ? you had to terminate every drive on the cable, so how was scsi ever superior to the ata standard in a real world situation?

[stormcrow]

Not to mention that scsi was a enterprise solutioun every other system used ide, and firewire was dead to begin with FireWire – Wikipedia was for some strange cameras that used it i think i had a motherboard with a firewire port sometime but it was never used and even the driver support in windows xp was well it was detected in the device manager.

And PC Card – Wikipedia is so old do you realy still use some old mobile card for a laptop ? i doubt that, i even doubt that any carrier still offers that kind of mobile service to begin with.

Oh and why is scsi superior to other standards ?

Scsi was the pro dude thing in the 90 it was serial and ide was parralel, and then came sata, serial transfers and sas and whatever.

Actually Pata(ide) was allready superior to scsi back then you only had to terminat 1 drive, 1 was master 2 was slave and you only could have 2 devcies on one slot.

Scsi allowed you like 7 drives ? you had to terminate every drive on the cable, so how was scsi ever superior to the ata standard in a real world situation?

Apple mostly used SCSI till SATA arrived on their desktops. IDE/ATA was absolutely NOT superior to SCSI (EVER!). SCSI had plenty of data integrity features built into the specification that IDE/ATA(PI) specifications purposely left out to make it cheaper for consumers.

SATA added much of the SCSI specification in order to improve the data communications robustness at the signal level. SCSI's superiority went much further than the number of peripherals it could accommodate on a single bus (6 peripherals + 1 controller = 7 devices, or in later cases 15 + 1, everyone seems to forget the controller took one of the slots). However, the SCSI bus was always a shared communications bus and only as fast as its slowest chain member. Arguably it wasn't the number of peripherals you could hang on a single SCSI chain. It was the data integrity protections you cared about. Work stations and high end servers used ECC RAM + SCSI buses for peripherals to make reasonably sure the data streams remained intact from memory to peripheral and back again, given the peripheral itself is otherwise reliable.

But even if you have a robust com signal specification, there's plenty of ways of screwing over your customers inside the peripheral itself. Soooo many horror stories. Just that the problems tended to be somewhat less common on SCSI devices (mostly because of their basic expense) than IDE/ATA or other interfaced peripherals. After all, you can have all the signal error correction and robustness you want between the main computer and peripheral, but if the peripheral is screwing you over internally you're still screwed.

[stiiixy]

SCSI inferior to PATA?

For rxactly the reason you mentioned; seven drives. It was enterprisr level, and a lot of serious work devices used it, like scanners.

And Im talking HIGH END room sized stuff. Apple vixes had FireWire interfaces, as there was nothing close for the speed and reliability. It wasnt an edge case, it just wasnt meant for PC, as USB consortium continually made cheap shit specs to keep it away.

Firewire cameras were A LOT better to work with, given the right equipment.

[ayumu]

If anyone would want such ancient PCMCIA NICs and modems for actual use, it'll be the BSD people.

What about Amiga users? A1200 and A600 have PCMCIA slots, and that's how we get our Amiga online.

[gotar]

Also, completely clueless with the rational for needing older hardware for converting old analog media materials to digital, assuming nowadays hardware is much better.

You're obviously not doing this kind of work. If you did, you would have known, that you cannot even put the old and new hardware into the same machine. Unless you do have some mysterious Xeon scalable motherboards with ISA slots (probably from the same sources, as Windows XP updates).

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.

Then use it. Problem solved.

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.

Of course, you can buy fresh new Windows XP in the local computer store. Probably with updates and drivers for current hardware. And with ISA bridges.

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.

FYI, as you keep mentioning this "Gentoo, a source based distribution". Most classical Linux distributions are source based.

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.

Fortunately you also have Rust support on your Windows XP.

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.

No problem! You've just volunteered to keep them up to date - open github account, fork the tree, keep going!
You know this git/hub things are free (as a beer) to use? You know what the "sources" ("Gentoo, a ... based ...") are, aren't you?

[gotar]

If a kernel module is not loaded then it is NOT loaded.

Are you aware that some part of the kernel are not loadable as modules? You are absolutely sure, that these drivers don't require such code?

E.g. config ISA_BUS is not tristate.

Real reason most of these get removed is that, since the kernel interface isn't stable (in the source code),

Memory management, DMA, threads, scheduling, locking, namespacing etc. are not kernel interfaces. There are many internals that are subject of updates and you need all the drivers that use anything like this to keep in par.

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.

Fortunately in this thread we've already found the second volunteer to do this. Because you are not lazy.

BTW please spare more of your free time and keep updating the udev rules. Especially for the pre-PnP devices (you know the "Plug and Play"?).

[gotar]

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.

Ever heard about existing database of kernel knobs that includes the version numbers? Do you know, that discoverable hardware (e.g. by PCI-ID) are registered for modules?

If you need more, go ahead.

The main point for my posts, many have spent money on the hardware and many have spent time submitting code,

I understand the desire for keeping the piece of work. It's not lost, it lives in our heart^W^W^W^H^H in git.

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

Nobody cares enough. Unless you do.

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.

Doesn't make any sense. If not maintained, they might simply exist in the older branches. If anyone needs such driver and makes it work again, there's no problem in moving it back to the main tree.

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.

ROTFL

But let's try this approach: when you post to phoronix, you need to keep responding indefinitely.