As the kernel moves on changes could be introduced that make them difficult to compile with the new kernel. Unmaintained doesn’t only mean not adding new features, it means keeping up with the rest of the code.
The GDM724x is removed for supporting the GCT GDM724x LTE chip based USB modem devices. This driver was merged back in 2013 but is being removed now as the driver isn’t being maintained and yields a maintenance workload, the manufacturer GCT doesn’t respond to any emails/support, there doesn’t appear to be any of the said chips easily available for purchase, there is not any hardware documentation available, and no apparent usage of this driver remaining in the Linux community. Removing the driver clears out 3.6k lines of code and lowers the maintenance burden for other kernel developers.
There was also a vulnerability discovered in July linked to this driver.
So yeah I understand that they chose to remove some drivers from the kernel.
But that’s true of all code in the kernel. If any change can break something then all broken bits will need fixing. Why not remove all drivers in case an update breaks them. Things can’t be preemptively fixed before breaking changes are made. A driver can be complete and only need updating if someone else breaks stuff, so leave it alone until then and only remove it I’d no one comes to fix it.
If any change can break something then all broken bits will need fixing.
Right. So the less decrepit, old code that contains annoying little time bombs, the less time spent fixing things.
But that’s true of all code in the kernel. […] Why not remove all drivers in case an update breaks them.
And how many people actually need these ancient drivers maintained? More than zero, sure, but how many more than zero?
Maintenance effort is a finite resource. Choosing where it gets spent is an executive decision. Every dev hour you assign to debugging some ancient driver that one or two enthusiasts might still want someday is a dev hour not spent on development of some new feature, or fixing a problem affecting thousands, potentially millions of known, current, active users.
We can’t maintain all code forever. At some point the theoretical value it may have is outweighed by its cost to keep alive, and it gets cut.
A driver can be complete and only need updating if someone else breaks stuff, so leave it alone until then and only remove it I’d no one comes to fix it.
That’s sort of where we’re at now, in a way.
Yes, all of these drivers presumably are still fully functional at the time of cutting. But the devs have essentially all decided, “We are not fixing these anymore” already. If any of these break for any reason, they would all be immediate candidates for axing by your system.
The reason they aren’t just left in with a “we’ll just run it until it dies, then!” mentality is because a project like the Linux kernel doesn’t want to be full of software with undefined mystery behavior where they can reasonably avoid it.
A chunk of code being part of it at all is an implicit promise of, “This is intended to function as-documented. If it does not, we are responsible to fix it.” But we already know no one will fix it. So instead it just becomes, “This chunk of code may or may not work. We don’t know and we don’t care, lol. Use at your own risk. If you can prove it’s broken, we’ll just remove it”.
The Linux kernel does not want to be full of code like that. All of its code should be reliable to build things on. If it’s coming out, it needs to be announced in advance so users have time to migrate. A “we will run it until it suddenly breaks” system doesn’t afford that. The feature ideally has to be sunset while it’s still functional.
“Unstable code, use at your own risk” projects are better relegated to optional packages. If someone wants to bundle up these ancient drivers and offer them as an optional package, they are free to do so. If there ends up being zero will from anyone to do even that, I guess it’s more evidence to how little the functionality was actually demanded.
They don’t just decide to remove a driver on a whim, there’s a whole process which involves reaching out to the original maintainers and seeing if anyone else wants to take it on among other things. Internet search is so poor these days, I can’t find the information on it.
As the kernel moves on changes could be introduced that make them difficult to compile with the new kernel. Unmaintained doesn’t only mean not adding new features, it means keeping up with the rest of the code.
From another article
There was also a vulnerability discovered in July linked to this driver.
So yeah I understand that they chose to remove some drivers from the kernel.
But that’s true of all code in the kernel. If any change can break something then all broken bits will need fixing. Why not remove all drivers in case an update breaks them. Things can’t be preemptively fixed before breaking changes are made. A driver can be complete and only need updating if someone else breaks stuff, so leave it alone until then and only remove it I’d no one comes to fix it.
Removing functionality just in case is daft.
It’s a divesting of unwanted responsibility.
Right. So the less decrepit, old code that contains annoying little time bombs, the less time spent fixing things.
And how many people actually need these ancient drivers maintained? More than zero, sure, but how many more than zero?
Maintenance effort is a finite resource. Choosing where it gets spent is an executive decision. Every dev hour you assign to debugging some ancient driver that one or two enthusiasts might still want someday is a dev hour not spent on development of some new feature, or fixing a problem affecting thousands, potentially millions of known, current, active users.
We can’t maintain all code forever. At some point the theoretical value it may have is outweighed by its cost to keep alive, and it gets cut.
That’s sort of where we’re at now, in a way.
Yes, all of these drivers presumably are still fully functional at the time of cutting. But the devs have essentially all decided, “We are not fixing these anymore” already. If any of these break for any reason, they would all be immediate candidates for axing by your system.
The reason they aren’t just left in with a “we’ll just run it until it dies, then!” mentality is because a project like the Linux kernel doesn’t want to be full of software with undefined mystery behavior where they can reasonably avoid it.
A chunk of code being part of it at all is an implicit promise of, “This is intended to function as-documented. If it does not, we are responsible to fix it.” But we already know no one will fix it. So instead it just becomes, “This chunk of code may or may not work. We don’t know and we don’t care, lol. Use at your own risk. If you can prove it’s broken, we’ll just remove it”.
The Linux kernel does not want to be full of code like that. All of its code should be reliable to build things on. If it’s coming out, it needs to be announced in advance so users have time to migrate. A “we will run it until it suddenly breaks” system doesn’t afford that. The feature ideally has to be sunset while it’s still functional.
“Unstable code, use at your own risk” projects are better relegated to optional packages. If someone wants to bundle up these ancient drivers and offer them as an optional package, they are free to do so. If there ends up being zero will from anyone to do even that, I guess it’s more evidence to how little the functionality was actually demanded.
They don’t just decide to remove a driver on a whim, there’s a whole process which involves reaching out to the original maintainers and seeing if anyone else wants to take it on among other things. Internet search is so poor these days, I can’t find the information on it.