[alsa-devel] Workable vintage driver support mechanism? (Re: [PATCH v3] ES938 support for ES18xx driver)

[Takashi Iwai]

At Mon, 6 Oct 2014 20:41:50 +0200,
Andreas Mohr wrote:
> 
> On Mon, Oct 06, 2014 at 04:13:12PM +0200, Takashi Iwai wrote:
> > At Mon, 6 Oct 2014 15:55:18 +0200,
> > Ondrej Zary wrote:
> > > ES938 does not depend on ES18xx and can be connected to any device with MIDI 
> > > interface. Maybe there are some other cards with this chip.
> > 
> > Please prove it :)
> 
> :(
> 
> > That said, I'm not willing to merge the patch in the current form.
> > One of the reason is that this can be implemented pretty easily in
> > user-space.  Another is that it's a deadly old device, and likely only
> > handful boards are still running in the world, thus no much motivation
> > to bloat the kernel code for that.  We're even discussing to get rid
> > of ISA codes from the kernel tree nowadays.
> > 
> > Sorry, the patch was submitted 10 years too late.
> 
> :((
> 
> Given that I hate the forces that are increasingly coming into play here
> (but of course I do see the bigger picture, namely of kernel tree bloat),
> I think I have an idea which might be useful to accept:
> for every piece of sufficiently "vintage" submission,
> people would be tasked with offering (or somehow ensuring)
> a sufficiently closely time-related cleanup in other places.
> 
> Thus, given a "diffstat penalty" (lines added minus lines removed)
> of the vintage support patch:
> 
> Additionally offer a cleanup patch
> which gets rid of redundantly implemented kernel tree functionality:
> - for 15 year old devices: 0.5 * diffstat_penalty
> - for 20 year old devices: 1.0 * diffstat_penalty
> - for 25 year old devices: 1.5 * diffstat_penalty
> - for 30 year old devices: whaaa?

The kernel bloat is one side, and your proposal would help to keep
figure.  But another side is the maintenance, as Clemens pointed.
It's obviously more difficult for exotic hardware devices.  So, it's
really case-by-case.

Speaking of this particular patch, however, the reason for NAK isn't
(only) the vintage.  There are other concerns as I raised, especially
the ugliness of the interface it uses, and this doesn't have to be a
kernel stuff at all.  You could implement it as a user-space alsa-lib
plugin as well.


Takashi