Removing support for old hardware from the kernel

Bergmann started by noting (to applause) that he recently removed support for eight processor architectures from the kernel. It was, he said, a lot of work to track down the right people to talk to before removing that code. In almost every case, the outgoing architectures were replaced — by their creators — by Arm-based systems. There probably are not any more architectures that can go anytime soon; Thomas Gleixner's suggestion that x86 should be next failed to win the support of the group.

James Bottomley said that he's seeing more bugs on 32-bit architectures slipping through; there are almost no developers left doing 32-bit builds anymore. He asked: can we deprecate 32-bit support? That idea didn't get 👁 Arnd Bergmann
far either; Christoph Hellwig said that he routinely deals with people running 32-bit systems. Intel still sells 32-bit-only cores, and customers are still using them. It was agreed that setting up more automatic testing of 32-bit architectures would be a good idea.

Bergmann moved on to another class of old architectures, which includes m68k and pa-risc, that is being kept alive by a small set of developers who continue to fix bugs and are "glad to be among the last ten people using it". Yet another set comprises old architectures that have been embedded into products that are still shipping; there are ARM9 cores being installed in air-conditioning systems now, he said. Some of these run new kernels, which is what we want. But it raises interesting support questions when current hardware is based on a 20-year-old chip, and that hardware is expected to run for another 20 years.

Subscribe today and elevate your LWN privileges. You’ll have access to all of LWN’s high-quality articles as soon as they’re published, and help support LWN in the process. Act now and you can start with a free trial subscription.

Those two groups of users of ancient hardware are mostly distinct, Bergmann said. At some point, the community needs to think about whether it should drop support for either or both of them. The recent removal of eight architectures made a lot of things easier; removing architectures like pa-risc, alpha, or itanium would make life easier yet. For example, the m68k architecture uses a number of internal APIs that no other architecture needs at this point; removing that architecture would enable removing the APIs as well. That architecture includes the oldest machine supported by the kernel: a Sun-3 workstation built in 1985.

Ted Ts'o suggested that an ultimatum could be made: either the m68k architecture stops using the old, deprecated timer API (for example) within one year or it is removed from the kernel. This kind of approach has worked well in the Debian community, he said; without it, things can drag on forever. Another possibility, suggested by Olof Johansson, would be to remove an architecture when toolchain support disappears. The problem there, according to Bergmann, is that the GCC developers tend to wait until kernel support is removed for an architecture before deleting it themselves.

Linus Torvalds said that there is more to the problem than architectures, though. The 3c503 network interface driver is still in the kernel, but nobody is running that hardware at the moment. Hellwig said that there was a recent purge of old network cards, but it didn't go far enough. Bergmann agreed that architectures are not the biggest problem at the moment; he mentioned the ISDN subsystem as one that should probably go.

Torvalds thought that perhaps it could be time to remove PCMCIA support, but he feared that some embedded systems still use it. That turns out to be the case, according to Bergmann. The oldest Arm processor currently supported is the StrongARM 11. Some Russian company recently bought a big pile of PDAs to use as tourist guides; these devices use that processor — and have PCMCIA slots. Hellwig also noted that there was a PCMCIA pull request for 4.20 on linux-kernel. Sometimes, though, hardware support can be removed even when users exist; Torvalds noted with chagrin that some dive computers use the recently removed IRDA infrared driver subsystem.

Bergmann said that he will often find a specific type of bug that turns out to be present in over 100 drivers; 70 of those, he said, are unlikely to be used by anybody. It would be good to find a way to remove those drivers. Torvalds said that, much of the time, it may turn out to be easier to just fix them. Bergmann answered that it's often obvious that the drivers are broken, but that doesn't mean they are entirely unused. Gleixner observed that the computing industry has trained users to not even blink an eye if their systems crash after a day of use; they just reboot and move on.

The session came to a close with some suggestions to add more old hardware to the various testing farms out there. But there was a distinct shortage of actionable solutions to the old-hardware problem, so that code is likely to be with us for some time yet.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel to the Maintainers Summit.]

Note: you can avoid this step in the future by logging into your LWN account.