Message-ID: <alpine.DEB.2.21.2408131802050.59022@angie.orcam.me.uk>
Date: Thu, 15 Aug 2024 22:20:49 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org, 
    Vojtech Pavlik <vojtech@....cz>, Jiri Kosina <jikos@...nel.org>, 
    Benjamin Tissoires <bentiss@...nel.org>
Subject: Re: [RFC PATCH 0/5] Removal of a few obsolete input drivers

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

Powered by blists - more mailing lists