On Thu, Aug 15, 2024 at 10:20:49PM +0100, Maciej W. Rozycki wrote: > 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. OK, so here is an example: https://lore.kernel.org/all/20241010194533.GA575181@bhelgaas/ We need to cleanup PCI core and the driver uses a hack. So we need to patch it. > > > > > 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. You are assuming that somebody actually needs them and will have to restore them. > > 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? I do not see how CONFIG_DEPRECATED help any better than revert. The driver will disappear, people will start looking for it and will complain on Linux Input/LKML. At which point we will revert either the config change or driver removal patch. If the argument that with config someone does not need git tree but rather can work with a tarball I say I really do not care for this case. > > 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. We are still willing to support old hardware, but only when it is actually used. Thanks. -- Dmitry
