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

[Takashi Iwai]

On Fri, 02 Sep 2016 13:30:33 +0200,
Takashi Sakamoto wrote:
> 
> Sorry to be late. I'm a bit busy for my daily work and things related
> to my poor life.
> 
> On Sep 1 2016 00:40, Takashi Iwai wrote:
> > Which application do you have in mind?
> 
> At first, I did never suggest that 'TLV feature should handle byte
> stream' or 'TLV feature should be extended to somewhere'. I just
> addressed that 'Now, TLV feature is not used only for transmission of
> pure threshold information between applications/drivers, but it's also
> used for I/O operation. Unfortunately, protocol of TLV packet payload is
> not kept anymore.'
> 
> It's not my intension to discuss about this patchset in a point of 'byte
> stream'. It comes from your bias, and the other developers are led to
> the wrong direction, sigh. I really hope them to read my comment in this
> patchset carefully and compare them to actual code implementations
> in driver/core/library and applications[1][2][3].

Well, without the particular purpose explained, it's hard to
understand why your patchset is required.  That was the failure.
The implementation details come after the design.


> Again, I have few interests about actual implementation of TLV feature
> in driver side and for what purposes applications are developed to
> utilize TLV feature. They're free for developers in each area now, and
> for future. What we should do is how to assist their activity via the
> design of APIs. This is my place in this patchset. It's not my intension
> to request extensions of TLV feature.

But your patchset changes the call patterns largely.  This annoyed me,
and supposedly most people, too.  If the TLV feature isn't needed to
be extended, the necessary change shouldn't be too intrusive, either.


> > Applications would access via either alsa-lib or tinyalsa.  And these
> libraries do already care about how to access via TLV.
> 
> Without enough care due to implementation in kernel land.
> 
> As I already cleared, current TLV feature has a difficulty not to return
> the length of actually handled bytes[4]. Correspondingly, APIs in these
> libraries have defections, as APIs for I/O operation or transmission of
> arbitrary data, because applications cannot get to know the actual
> length of handled data.

It's TLV, so the actual length is always encoded in the block (in
tlv[1]).  What's missing...?


> There's no way for user space to get appropriate length in advance, this
> brings contradiction for content of given buffer. For example, in ALSA
> SoC part, the length is trimmed according to a parameter of driver
> instance, implicitly[5]. As a result, users are beguiled. They requests
> a certain length of buffer to be handled via TLV feature. Even if they
> receive success, a _part_ of buffer is actually handled. This is not
> good for software stacks in a point of abstraction layer of hardware.
> There's no transparency independent from hardwares. Application
> developers is forced to consider about device driver's codes which are
> not open via APIs.
> 
> I already wrote patchset for alternative TLV APIs to alsa-lib:
> https://github.com/takaswie/alsa-lib/tree/new-tlv-api
> 
> In the remote branch, you can see new APIs at commit 5f13de, which
> allows applications to receive the length of actually handled data:
> https://github.com/takaswie/alsa-lib/commit/5f13deacfc65d26d6acbb066da0f2c35538f7497
> 
> 
> > What makes better what, practically seen?
> 
> Already described in this message.
> 
> If you're still against to this patchset, I'm OK to cancel this discussion.
> 
> But in this case, involuntarily, when my friends are going to use TLV
> feature for their ALSA applications (I hope it's unlikely), I'll
> recommend them not to use it, because it certainly confuses application
> developers and bring them to particular-hardware-specific something with
> the lack of transparency. That's a waste of their expensive time.

The usage of TLV for this type of communication has *NEVER* been
recommended.  That's why I wrote it was an "(ab)usage".  It was
accepted just because the proposed usage fitted with the current TLV
access pattern.  If it were for more generic purpose, it wouldn't have
been accepted from the beginning.

The extended API is merely to pass a large blob over the control API.
That's the only purpose, and wouldn't be more than that.


thanks,

Takashi


> [1] Apparently, Vinod Koul didn't read the comment before joining in
> this discussion. He did the same behavior to my former patchset.
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-July/110335.html
> 
> I don't prefer prompt responses just to external stimulus, because we're
> not wild animals but human being with reasons. I use my private time to
> this project and hope to avoid wasting my life for this kind of
> unreasonable communication, because good communication is based on
> enough understandings in each side.
> 
> [2] Charles Keepax still seem to have interests only in hardware to
> which he's currently related. He presumably has no good view for API
> designs for long term usage.
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/112378.html
> 
> [3] Clemens got near to where I stand. He already gave me his idea to
> this patchset, with an alternative idea. I'm really appreciate for his
> judgment, even if it's against my idea. His advices have often helped
> me, then I respect his way to work for this subsystem.
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/112373.html
> 
> [4] [alsa-devel] [PATCH 1/4] ALSA: control: return payload length for
> TLV operation
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/112398.html
> 
> [5]
> http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/soc/soc-ops.c?h=v4.8-rc4#n772
> 
> 
> Regards
> 
> Takashi Sakamoto
>