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
