Message-ID: <s5hd29wzf84.wl-tiwai@suse.de>
Date:	Mon, 13 Oct 2014 07:54:51 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Ondrej Zary <linux@...nbow-software.org>
Cc:	Andreas Mohr <andi@...as.de>, 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 Sun, 12 Oct 2014 23:19:04 +0200,
Ondrej Zary wrote:
> 
> 
> 
> On Tuesday 07 October 2014 07:32:18 Takashi Iwai wrote:
> > 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.
> 
> So do I understand correctly that there is no (right) way for a kernel driver 
> to issue MIDI commands?

Not in the form as you used.  The driver could poke the internal I/O
instead, or introduce a better way to integrate without fs ops.  In
the latter case, we need to introduce a new API, and it's not worth
only for this driver, though.

> Is it possible for an alsa-lib plugin to automatically load when an ES18xx 
> sound card is present to check for ES938 (without repeating the detection on 
> each application launch)?

A good question.  IMO, it's easier to let user choose via the static
configuration in this case.  It's an ISA device, after all, no hotplug
device.  You can fiddle with udev and create a config on the fly at
boot time, too.


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/

Powered by blists - more mailing lists