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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hr3ykla1p.wl-tiwai@suse.de>
Date:	Tue, 07 Oct 2014 07:32:18 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Andreas Mohr <andi@...as.de>
Cc:	Ondrej Zary <linux@...nbow-software.org>,
	alsa-devel@...a-project.org,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Workable vintage driver support mechanism? (Re: [alsa-devel] [PATCH v3] ES938 support for ES18xx driver)

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/