[alsa-devel] [PATCH] Revert "ASoC: core: mark SND_SOC_BYTES_EXT as deprecated"

[Mark Brown]

On Fri, Sep 16, 2016 at 10:21:12PM +0900, Takashi Sakamoto wrote:
> On Sep 16 2016 19:52, Mark Brown wrote:

> > Please submit patches using subject lines reflecting the style for the
> > subsystem.  This makes it easier for people to identify relevant
> > patches.  Look at what existing commits in the area you're changing are
> > doing and make sure your subject lines visually resemble what they're
> > doing.

> OK. But the different fashion in ALSA SoC part from ALSA itself often
> puzzles me.

ALSA patches don't usually start "Revert" either...

> > > However, SND_SOC_BYTES_TLV brought confusions to user land because it
> > > doesn't follow to a protocol of ALSA control interface. At least, this
> > > macro and related kernel APIs include two misunderstandings:
> > >  - 'struct snd_ctl_elem_info.count' can also represent the length of TLV
> > >    packet paylaod, snd_soc_bytes_info_ext() performs in this way.
> > >  - 'struct snd_ctl_tlv.tlv' can include arbitrary data regardless of TLV
> > >    packet structure, snd_soc_bytes_tlv_callback() performs in this way.

> > I can't tell what problem you are trying to describe here, sorry.  What
> > are you expecting the userspace ABI to do that these controls don't,
> > you appear to be saying that the code does actually do what's expected
> > which obviously isn't a problem.

> These two APIs don't perform what to be expected in a point of application
> interface. These two items are not what to be expected in a point of
> application interface, but what they do wrong.

In what concrete way do they not do what is expected?

> > What do you expect to happen, what is
> > actually happening and why do you beleive this to be a problem?

> This patchset comes from a conclusion of this thread:

We need someone reading the changelog to be able to identify what the
change is doing, especially for something like this which is visible
outside the kernel.

> > Having two randomly different interfaces is not going to help
> > that or stop the larger controls existing, it'll just make the interface
> > more confusing for driver authors.

> On the other hand, when some driver developers actually follow to the
> message which I'd like to purge, then abuses of the interface are increased.
> Near future, it will bring confusions and disorder to ALSA applications. And
> the cause is hard to be identified from user land, because few developers
> think drivers lose protocol of application interface in fact.

> Of cource, there's a need to work more to solve this issue. This is quite a
> small part of it.

This isn't really going to help that too much unfortunately given that
one of the users of the new interface is the Intel drivers which are
presumably going to be one of the most common things applications
encounter.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20160916/bb342d02/attachment-0001.sig>