| Message ID | 20240808172733.1194442-1-dmitry.torokhov@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Removal of a few obsolete input drivers | expand |
On Thu, 8 Aug 2024, Dmitry Torokhov wrote: > I am wondering if it is not the time to retire bus mice drivers since > they have been out of favor for close to 30 years, as well as 3 drivers > for portables from late '90s to early 2000. Are these drivers broken, e.g. fail to compile or crash the system? Otherwise what's the gain from removal? Maciej
On Fri, Aug 09, 2024 at 01:24:42AM +0100, Maciej W. Rozycki wrote: > On Thu, 8 Aug 2024, Dmitry Torokhov wrote: > > > I am wondering if it is not the time to retire bus mice drivers since > > they have been out of favor for close to 30 years, as well as 3 drivers > > for portables from late '90s to early 2000. > > 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. > Otherwise what's the gain from removal? 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. Thanks.
On Sun, 11 Aug 2024, Dmitry Torokhov wrote: > > > I am wondering if it is not the time to retire bus mice drivers since > > > they have been out of favor for close to 30 years, as well as 3 drivers > > > for portables from late '90s to early 2000. > > > > 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? > > Otherwise what's the gain from removal? > > 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. Maciej
On Mon, Aug 12, 2024 at 02:53:30PM +0100, Maciej W. Rozycki wrote: > On Sun, 11 Aug 2024, Dmitry Torokhov wrote: > > > > > I am wondering if it is not the time to retire bus mice drivers since > > > > they have been out of favor for close to 30 years, as well as 3 drivers > > > > for portables from late '90s to early 2000. > > > > > > 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? > > > > Otherwise what's the gain from removal? > > > > 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. Thanks.
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
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.