Dropping x86 EISA support

It is clear that Paul Gortmaker thought there was a pretty good chance to get rid of some old, unloved code when he proposed dropping support for the EISA bus from 32-bit x86 kernels. As he noted, when support for the MCA bus was dropped in 2012, Linus Torvalds mused that perhaps EISA could follow suit "some day". Obviously Gortmaker hoped that day had come, at least for the x86 architecture, but it seems he was a bit premature.

As Gortmaker pointed out, there are some architectures that are essentially "frozen in time (from a hardware perspective)"—he mentioned Alpha and PA-RISC as examples—so EISA support cannot be completely removed from the tree (as MCA was). Removing it from x86 did not save much in the way of code—it only deleted a little over 100 lines—but he had something else in mind:

But Maciej W. Rozycki was not on board with the removal, noting that it is needed "to support EISA FDDI [Fiber Distributed Data Interface] equipment I maintain if nothing else". He suggested that perhaps it could be hidden behind a configuration option for "more exotic stuff" so that not everyone needed to build and test it.

Unsurprisingly, Torvalds was quick to put the kibosh on EISA's removal: "So if we actually have a user, and it works, then no, we're not removing EISA support". But it is instructive to consider what might have happened if Rozycki had not posted his disagreement. It seems quite possible that if no one spoke up for EISA on x86, it might well have been removed.

There is always some tension in the kernel community between those who want to clean up and clear out "legacy" code and those who want to see it continue to live in the mainline tree. There is a cost associated with maintaining legacy code, though, even if it rarely needs to change, and it does continue to get built as part of various kernel-wide testing efforts. That puts some (possibly small) amount of burden on many other kernel developers, most of whom are not interested in the old code at all.

As certain kinds of hardware start to disappear entirely—from the kernel developers' consciousness, at a minimum—it behooves those using Linux on that hardware to pay attention to the kernel mailing list. As seen here, real users who do speak up will likely be able to block efforts to remove support, but timely responses will be needed. If a kernel release cycle or two goes by, it may well be too late.