Peter Huewe: Deprecation / Removal of old hardware support

September 13, 2018

Related Material:

  1. Shedding old architectures and compilers in the kernel.

LWN QoTW:

One big problem with removing code in general is that code that becomes unmaintained often also has nobody left that knows about it being unmaintained.

— Arnd Bergmann

Additional Participants: Alexander Sverdlin, Arnd Bergmann, Daniel Vetter, Geert Uytterhoeven, Greg KH, Guenter Roeck, Laurent Pinchart, Linus Walleij, Lukasz Majewski, Mark Brown, and Thomas Gleixner.

Peter asked about the process for removing support for old hardware, using as an example the old TPM1.1b-based devices, which Peter suspects have not been manufactured for about 10 years. Linus Walleij said that as long as the hardware in question has active users building and running new kernels, Linux-kernel support for that hardware should be retained. Linus gave m68k and ARMv4 as examples of old hardware with active users. Arnd Bergmann outlined how he removed the unmaintained architectures, including contacting core developers (or, failing that, the company owning the architecture's IP) and gaining agreement. Arnd called out two notable categories of obsolete platform ports:

Arnd also noted that dead hardware often has special device-driver hacks in non-obvious places that is only needed to support the now-dead hardware. Finding and removing all of these special hacks can be non-trivial.

Arnd also noted that removing an architecture from current GCC does not necessarily imply removing Linux-kernel support, at least not until Linux stops supporting the older versions of GCC. Guenter Roeck noted that no version of GCC supported by current mainline can build unicore, so perhaps it is time to remove unicore from the kernel. Geert Uytterhoeven countered by demonstrating how current kernels can in fact build unicore by reverting a pair of commits (815f0ddb346c1960 and 815f0ddb346c1960), which effort resulted in one recent bug fix and two code improvements. Guenter asked how Geert avoided this issue, prompting Geert to recall an additional patch that was required. Guenter proved reluctant to maintain a unicore-specific patch stack. Although Daniel Vetter seemed to sympathize with Guenter's reluctance, he said that his project maintained a topic branch containing reverts and patches needed at any given point in time to keep their CI system happy.

Linus pointed out that ARMv4 is used in IoT for civil infrastructure, which makes them an attractive attack vector, which is countered by patching and upgrading. Therefore, removing them from the kernel (thus shutting of the flow of security patches/upgrades) might be considered irresponsible. Linus believes that some “obsolete” architectures will be in use for another 20-30 years, so ARMv4 removal might not be immanent. Lukasz Majewski supported and amplified Linus's view. Greg KH suggested upgrading to newer kernels and also suggested that Linus and Lukasz look into the Linux Foundation Civil Infrastructure Platform. Laurent Pinchart felt that Greg misunderstood Lukasz's point, arguing that it was the lack of support for old hardware in new kernels that was forcing IoT device vendors to use very old kernels, arguing that the old hardware should be treated as first-class citizens of new kernels. Greg reiterated that he does not want to drop support for anything that anyone is actually using, but that one problem is that no one tells the Linux kernel community when something is no longer used. Greg uses the staging tree to test interest: If no one complains when he moves something to staging, he assumes that it is no longer in use. Peter suggested formalizing a 10-release-cycle sojourn in staging, and accompanying it with boot-time warnings. Greg prefers a three-release-cycle sojourn, and his experience indicates that no one reads the warnings. Greg is OK moving the code, noting that “git mv” is easy to use.

Mark Brown suggested using -stable to support old hardware and also to apply -stable principles to the design of hardware that is intended to be long-lived. Linus said that this approach had in fact been used by MOXA for their ART SoC, samples of which can easily be obtained. Arnd likes the idea of keeping up with new kernels, but argues that projects eventually settle on an LTS version. Arnd also asked for specific examples of 20-30-year deployments so that he can include them in his year-2038 presentation. Alexander Sverdlin several images of devices that he said were widely installed across Russia in 2006 (with ample Cyrillic to prove it), and that he expected that these would remain in service for quite some time. Alexander also noted that this situation is what led him to take on the maintainer role for the EP93xx.

Thomas Gleixner noted that support of old hardware should not necessarily imply support of old compilers. Geert said that the issue was the GCC dropped ARMv4 (but not ARMv4T) support. This was Arnd's cue to lay out the GCC support situation for various ARM families, and also to reaffirm that there is currently no plan to deprecate ARMv4T in GCC.