All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [RFC PATCH] docs: sound: kernel-api: writing-an-alsa-driver.rst: add FIXMEs
Date: Fri, 21 Apr 2023 10:55:23 +0200	[thread overview]
Message-ID: <87leilsjgk.wl-tiwai@suse.de> (raw)
In-Reply-To: <ZEFl5hlFL/VAIVTB@ugly>

On Thu, 20 Apr 2023 18:18:46 +0200,
Oswald Buddenhagen wrote:
> 
> On Thu, Apr 20, 2023 at 04:27:35PM +0200, Takashi Iwai wrote:
> > But why this has to be buried in the middle of a patch containing lots
> > of other changes...?  Better to split out and start a new thread.
> > 
> this "patch" doesn't contain any changes, only a bunch of questions.
> given the expected audience, i don't think that "burying" it was
> detrimental.

Well, a patch is basically for patching -- i.e. fixing / correcting
the stuff.  For the basic API design topic, you could start off a
thread, not as a form of a patch.

> > IIRC, this was a result after struggles with the structured control
> > implementations.  It became too complex, and the plain array with
> > string representation can cover all complexity, while it still allows
> > the grouping in user-space side.
> > 
> i can see how a keyword based interface description is appealing - it
> keeps the kernel interface slim and flexible. but of course that comes
> at a steep cost in user space - i for one got completely lost and was
> unable to debug the bug described in the OP.
> maybe a middle way would have been the best option?

I don't mean that the current API is the best form, either.
OTOH, it's been used for very long time, and the history tells that
it's "good enough".

> > Again, the choice was done in a quarter century ago, and if you change
> > it, you'll certainly break the whole things badly.  We must keep the
> > compatibility.
> > 
> i don't intend to actually change it. but suppose we did.
> 
> i suppose we'd have to add SNDRV_CTL_ELEM_ACCESS_{PLAYBACK,CAPTURE}.
> both could be set for unspecific and actually bidirectional
> controls. if neither is set, user space would fall back to the keyword
> based rules (and exceptions ...) - that would be backwards compatible
> and would enable a gradual migration.

The backward compatibility isn't really easy as you wrote, I'm
afraid.  If you run an old user-space stuff on the new kernel, you
must not fill that new information bit but translate it to the string
suffix instead; and that has to be done inside the kernel
automagically.


Takashi

  reply	other threads:[~2023-04-21  8:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 20:12 [RFC PATCH] docs: sound: kernel-api: writing-an-alsa-driver.rst: add FIXMEs Oswald Buddenhagen
2023-04-06  6:42 ` Takashi Iwai
2023-04-20 12:47   ` Oswald Buddenhagen
2023-04-20 12:54     ` Takashi Iwai
2023-04-20 13:44       ` Oswald Buddenhagen
2023-04-20 14:27         ` Takashi Iwai
2023-04-20 16:18           ` Oswald Buddenhagen
2023-04-21  8:55             ` Takashi Iwai [this message]
2023-04-21  9:11               ` Oswald Buddenhagen
2023-04-21  9:14               ` Jaroslav Kysela

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=87leilsjgk.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=oswald.buddenhagen@gmx.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.