[alsa-devel] [PATCH 1/4] ALSA: control: return payload length for TLV operation

[Takashi Iwai]

On Tue, 30 Aug 2016 09:13:54 +0200,
Takashi Sakamoto wrote:
> 
> On Aug 30 2016 15:59, Takashi Iwai wrote:
> > On Tue, 30 Aug 2016 08:19:46 +0200,
> > Takashi Sakamoto wrote:
> >>
> >> On Aug 30 2016 14:29, Takashi Iwai wrote:
> >>> On Tue, 30 Aug 2016 01:44:42 +0200,
> >>> Takashi Sakamoto wrote:
> >>>>
> >>>> TLV feature of control interface is originally introduced at
> >>>> commit 42750b04c5ba ("[ALSA] Control API - TLV implementation for
> >>>> additional information like dB scale") and commit 8aa9b586e420 ("[ALSA]
> >>>> Control API - more robust TLV implementation"). In this time,
> >>>> snd_kcontrol_tlv_rw_t is for generating and transferring information about
> >>>> threshold level for applications.
> >>>>
> >>>> This feature can transfer arbitrary data in a shape of an array with
> >>>> members of unsigned int type, therefore it can be used to deliver quite
> >>>> large arbitrary data from user space to in-kernel drivers via ALSA control
> >>>> character device. Focusing on this nature, commit 7523a271682f ("ASoC:
> >>>> core: add a helper for extended byte controls using TLV") introduced
> >>>> snd_soc_bytes_tlv_callback() just for I/O operations.
> >>>>
> >>>> In this case, typically, APIs return operated length, while TLV feature
> >>>> can't. This is inconvenient to applications.
> >>>
> >>> The ASoC TLV (ab)usage still takes / receives the length field of
> >>> TLV.  What's missing there?
> >>
> >> I don't get exactly what you mean.
> >>
> >> The issue in which I'm interested is that applications cannot get to
> >> know length of actual processed bytes. Nothing others.
> >>
> >> When pure threshold level information is transferred, applications can
> >> get its length of TLV packet payload, because we have a loose protocol
> >> to store the length of data in second element of the payload. The size
> >> of 2 elements plus the length equals to the length of TLV packet
> >> payload.
> >>
> >> When using TLV feature just for I/O, this protocol is not kept, as we
> >> can see implementation of 'soc_bytes_ext' operation. Thus, the number
> >> of processed bytes should be returned to applications, by any
> >> ways. This patchset uses 'length' field in TLV packet header.
> >
> > The current way of ASoC ext ctl is intended to be a workaround to pass
> > a large data via ctl API.  Nothing more than that.  If it's used for
> > receiving arbitrary size of data from the driver, it's a buggy usage.
> 
> It's not workaround, it's actually used.

... more than passing a large data?  If yes, it must be a bug.

> It's better to consider as
> one of supported ways and pay enough attention so that applications
> don't get disadvantages from it.
> 
> The way to use is depending on actual implementation of each
> driver. It's better not to force policy of the usage to driver
> developers, I think.

I don't agree, sorry.  The soc ext ctrl was introduced just for
passing a large set of data.  Nothing more than that.  If we need to
handle the processed data size in return, TLV is no right API to use
at all.  It just needs to use another API.

TLV callback can notify whether it handles all or it fails.  That's
enough for the control elements.  What else do you expect?


Takashi