KS2012: Supporting old/oddball architectures, tool chains, and devices

H. Peter Anvin began his presentation on the first day of the 2012 Kernel Summit by noting that Linux supports an astonishing variety of hardware. In particular, it offers long-term support for older hardware, and is popular with some users for precisely that reason. Most of the time, supporting older and unusual hardware and tool chains is a worthwhile activity. Nevertheless, Peter's question was: what limits does the kernel development community want to set on the amount of effort invested in supporting old or unusual hardware architectures, build tool chains, and devices?

Peter's point is that supporting old and oddball systems inevitably has associated effort and problems. When it comes to supporting these systems, there is a balancing act: those systems may matter a lot to a small set of users, but supporting them imposes a development burden across a wide spectrum of the kernel development community.

Peter gave a few examples. The kernel still includes code to support old Intel 386 CPUs (i.e., the predecessor to 486 chips that appeared in 1989). One might ask whether anyone out there is still trying to boot Linux on such old hardware. However, Peter noted that as an x86 maintainer he had recently received a bug report from someone trying to boot Linux on such a system. But the genesis of that bug report is interesting. In essence, it came from someone who asked themselves, would I be able to boot a modern Linux kernel on this ancient system that I happen to have lying around? In response, Peter's question is, should the kernel developer community continue to invest effort to support such users?

There are various difficulties associated with supporting old and obscure systems. For example, maintainers may want to make kernel changes that could impact code that supports legacy systems, but it may be difficult to assess what that impact may be. Furthermore, it's unlikely that a maintainer will have the hardware needed to test the impact of changes that affect legacy code. Legacy code thus becomes rarely executed code, and rarely executed code is code that hides breakages and security holes. (Peter noted that architecture-specific "hooks" are the "common" solution for dealing with oddball architectures. Such hooks are a form of "come from" code about which it is very difficult to reason. The only way of dealing with that difficulty is careful documentation of the hook preconditions, postconditions, and invariants. It may come as no surprise that the likelihood that such documentation exists falls "somewhere between rarely and never".)

There are a few questions to consider when deciding whether to continue to support a legacy system. For example, do users of that system exist, how numerous are they, and how important is it to continue supporting them with modern kernels? The problem is that it is difficult to obtain data that answers these questions for obscure systems. In particular, Peter questioned the notion that bug reports equate to active users.

Legacy build tool chains present a similar problem. Peter notes that "People complain when we introduce something that triggers a bug in a 7-year-old tool chain. At some point we need to be able to say: if you want to use a new kernel, you've got to be prepared to install an appropriate tool chain."

Peter extended his discussion of legacy support to include user-space interfaces. One example he gave was compatibility code that has been unused for a long time. As a specific case, a.out support on x86-64 has been the source of several serious security holes; however, the a.out executable format was already largely obsolete by time the x86-64 architecture arrived, and likely has never seen serious use. Is there any good reason to support such obsolete interfaces, and is there a sane path to deprecating and removing them?

At this point, Linus spoke up to detail his stance on changes to user-space interfaces: "I never said don't change the ABI. We have done it to fix bad bugs. Just don't break user space. If we can change the ABI, but no one complains, then we are good to go." As a step in the removal process, Rusty Russell proposed the addition of a CONFIG_MODERN option that would be on by default, and could be disabled if access is needed to legacy features. Len Brown responded that this would likely suffer a similar fate to CONFIG_EXPERIMENTAL, which was always turned on (i.e., CONFIG_MODERN would likely always be turned off by distributors). Thomas Gleixner instead suggested to place legacy features under configuration options marked as "bool n", preventing the options from being selected, and then removing the legacy features unless someone complains within a reasonable time.

The session ended without any particular conclusions, but a few people expressed sentiments in favor of removing support for legacy systems, and no one raised serious objections. Thus, it may be that in the future we see some serious effort devoted to cleaning out kernel code for systems that clearly see no serious contemporary use. (It is noteworthy that a discussion on removing stale platforms was also taking place in the ARM minisummit.)