mbox series

[RFC,0/5] Removal of a few obsolete input drivers

Message ID 20240808172733.1194442-1-dmitry.torokhov@gmail.com
Headers show
Series Removal of a few obsolete input drivers | expand

Message

Dmitry Torokhov Aug. 8, 2024, 5:27 p.m. UTC
Hi,

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.

Please let me know what you think.

Thanks,
Dmitry

Dmitry Torokhov (5):
  Input: inport - remove driver
  Input: logibm - remove driver
  Input: pc110pad - remove driver
  Input: mk712 - remove driver
  Input: ct82c710 - remove driver

 drivers/input/mouse/Kconfig        |  36 -----
 drivers/input/mouse/Makefile       |   3 -
 drivers/input/mouse/inport.c       | 177 ---------------------
 drivers/input/mouse/logibm.c       | 166 --------------------
 drivers/input/mouse/pc110pad.c     | 160 -------------------
 drivers/input/serio/Kconfig        |  13 --
 drivers/input/serio/Makefile       |   1 -
 drivers/input/serio/ct82c710.c     | 239 -----------------------------
 drivers/input/touchscreen/Kconfig  |  12 --
 drivers/input/touchscreen/Makefile |   1 -
 drivers/input/touchscreen/mk712.c  | 215 --------------------------
 11 files changed, 1023 deletions(-)
 delete mode 100644 drivers/input/mouse/inport.c
 delete mode 100644 drivers/input/mouse/logibm.c
 delete mode 100644 drivers/input/mouse/pc110pad.c
 delete mode 100644 drivers/input/serio/ct82c710.c
 delete mode 100644 drivers/input/touchscreen/mk712.c

Comments

Dmitry Torokhov Aug. 12, 2024, 4:50 a.m. UTC | #1
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.
Maciej W. Rozycki Aug. 12, 2024, 1:53 p.m. UTC | #2
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
Dmitry Torokhov Aug. 12, 2024, 4:46 p.m. UTC | #3
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.
Maciej W. Rozycki Aug. 15, 2024, 9:20 p.m. UTC | #4
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