All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Zary <linux@rainbow-software.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Andreas Mohr <andi@lisas.de>
Subject: Re: Workable vintage driver support mechanism? (Re: [PATCH v3] ES938 support for ES18xx driver)
Date: Sun, 12 Oct 2014 23:19:04 +0200	[thread overview]
Message-ID: <201410122319.05127.linux@rainbow-software.org> (raw)
In-Reply-To: <s5hr3ykla1p.wl-tiwai@suse.de>



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?

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)?

-- 
Ondrej Zary

WARNING: multiple messages have this Message-ID (diff)
From: Ondrej Zary <linux@rainbow-software.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: Andreas Mohr <andi@lisas.de>,
	alsa-devel@alsa-project.org,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Workable vintage driver support mechanism? (Re: [alsa-devel] [PATCH v3] ES938 support for ES18xx driver)
Date: Sun, 12 Oct 2014 23:19:04 +0200	[thread overview]
Message-ID: <201410122319.05127.linux@rainbow-software.org> (raw)
In-Reply-To: <s5hr3ykla1p.wl-tiwai@suse.de>



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?

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)?

-- 
Ondrej Zary

  reply	other threads:[~2014-10-12 21:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-29 21:44 [PATCH v3] ES938 support for ES18xx driver Ondrej Zary
2014-09-29 21:44 ` Ondrej Zary
2014-09-29 21:58 ` Andreas Mohr
2014-10-06  9:39 ` [alsa-devel] " Takashi Iwai
2014-10-06 13:55   ` Ondrej Zary
2014-10-06 14:13     ` Takashi Iwai
2014-10-06 18:41       ` Workable vintage driver support mechanism? (Re: [alsa-devel] [PATCH v3] ES938 support for ES18xx driver) Andreas Mohr
2014-10-06 19:41         ` [alsa-devel] Workable vintage driver support mechanism? (Re: " Clemens Ladisch
2014-10-07 10:44           ` One Thousand Gnomes
2014-10-07  5:32         ` Takashi Iwai
2014-10-07  5:32           ` Workable vintage driver support mechanism? (Re: [alsa-devel] " Takashi Iwai
2014-10-12 21:19           ` Ondrej Zary [this message]
2014-10-12 21:19             ` Ondrej Zary
2014-10-13  5:54             ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201410122319.05127.linux@rainbow-software.org \
    --to=linux@rainbow-software.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=andi@lisas.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.