The Linux kernel community is currently debating a significant proposal that could see countless legacy network drivers purged from the mainline source code to combat an unsustainable surge in AI-driven bug reports. This development follows a patch series submitted by OG developer Andrew Lunn to the netdev mailing list earlier this week.
Maintaining support for old hardware has always been a “thing” for Linux. However, thanks to AI-wielding “detectives,” the sheer number of reports is forcing a shift in the kernel’s long-standing philosophy. Developers must now choose between addressing countless low-quality or hallucinated reports on systems no one uses or focusing their limited time on modern, high-impact subsystems.
Andrew Lunn argued that while support for aging ISA and PCMCIA-era hardware was once a low-maintenance endeavor, it has recently become a disproportionate burden due to newbies using AI and fuzzers to uncover theoretical defects in code that likely have no remaining active users.
Article continues below
"These old drivers have not been much of a maintenance burden until recently,” writes Lunn. “Now there are more newbies are using AI and fuzzers to find issues, resulting in more work for Maintainers. Fixing these old drivers makes little sense if it is not clear they have users.”
Linux patches to remove ancient network drivers from kernel source tree (Image credit: Linux Kernel Community)
Lunn notes that many of the Ethernet devices date to the late 1900s and feature ISA or PCMCIA interfaces (although there are a few that debuted between 2001 and 2002). If accepted, Lunn's proposal would remove specific drivers from 3Com, AMD, SMSC, Cirrus Logic, Fujitsu, Xircom, and 8390-based hardware families, eliminating approximately 27,646 lines of code from the kernel source tree.
More importantly, rather than nuking support all at once, Linux would handle the removal one patch at a time, meaning a user could restore any of these drivers if they still depend on them and are willing to step in as a maintainer. This approach would ensure that legacy systems are not permanently locked out, but no longer impose an ongoing maintenance burden by default.
Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.