Message-ID: <ZxgRXmPZrhKUegon@google.com>
Date: Tue, 22 Oct 2024 13:55:58 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
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 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

Powered by blists - more mailing lists