On Mon, 12 Aug 2024, Dmitry Torokhov wrote: > > > > Are these drivers broken, e.g. fail to compile or crash the system? > > > > > > I have no idea because I doubt that anyone has tested them since > > > forever. > > > > What's the rationale for your conclusion? How do you know nobody uses > > them? > > Because they are either require ISA add-on cards and it is quite hard to > find devices that still work, and are supported by the current kernel, > or internal peripherals in devices that are no longer useful. Do you > expect anyone using "Gateway AOL Connected Touchpad" in the year of our > Lord 2024? Maybe, maybe not. I certainly use Linux with actual ISA hardware, i.e. systems with ISA or EISA slots and option cards within, as well as other hardware dating back to 1989. I'm told people use Linux with m68k hardware going back in time even further. I don't use any of the bus mice themselves though (having had perhaps a more common serial mouse instead), but if the drivers build just fine, then I fail to see a reason to dump them. > > > The same gain that we get from removing obsolete boards and > > > architectures - less maintenance burden, less work when we need to > > > change some APIs, less energy burnt by 0-day and other bots, CI systems, > > > etc, compiling useless drivers over and over and over. > > > > Well, you don't have do do anything about these drivers, do you? They > > don't scream for food. And as to the energy, well I doubt this really > > matters, the amount is noise lost in the overall consumption. > > I kind of do even if they did not require much involvement. > > Let me ask this: why do you want to keep them? Do you know of a large > (or small) userbase of bus mice enthusiasts? Note that it would be very > easy to "git revert" the removal if someone actually needs this. There is burden involved as well as repo clutter from going through an apply/revert cycle though. Sometimes we do want to discard code, because it causes burden elsewhere. It was the case with the removal of support for the original 80386 CPU due to its lack of user page write-protection in the kernel mode, which in turn required us to have explicit checks carefully sprinkled throughout and painfully maintained. That hindered generic code and was a good argument in favour to removal as soon as 80386 became unimportant enough. In this case the decision seems arbitrary, the presence of these drivers does not hurt anything else. I agree it might well be that nobody uses them anymore (though someone may come across a relevant piece of hardware anytime and wish to try it with Linux; I do it from time to time, and I also have old stuff even I'd like to write entirely new drivers for if I ever find some time for that, i.e. I have sorted higher priority stuff), which I can sort of recognise as an argument in favour of discarding them. I'm not entirely convinced it's enough of an argument by itself, however if there are other people who think otherwise, can we please at least do it in stages such as some other projects do? That is require an explicit action for any interested party to keep the drivers enabled, say by hiding them behind CONFIG_DEPRECATED or suchlike (with clear documentation saying it's for stuff slated for removal), wait a year or two, and only if nobody speaks out during that period, then actually retire the code in question? A part of the joy with Linux for me and I believe other people as well it has been the ability to do odd stuff just for the sake of it. It used not to be business back in 1990s and it still not is, not at least entirely, for such a Linux old-timer as I have now oddly enough become. Maciej
