Re: [PATCH v2] kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest

[Takashi Iwai <tiwai@suse.de>]

On Tue, 07 Dec 2021 15:25:00 +0100,
Mark Brown wrote:
> 
> On Tue, Dec 07, 2021 at 12:20:32PM +0900, Takashi Sakamoto wrote:
> > On Mon, Dec 06, 2021 at 04:03:05PM +0000, Mark Brown wrote:
> 
> > I think it safer to take care of volatile attribute when comparing read
> > value to written value. I'm glad if you review below patch.
> 
> Yes, that's a good spot, it was an oversight to not take care of
> volatile controls - I'll roll that in if I send a new version or
> I guess Takashi could apply on top of my v2?  If people are mostly happy
> and at Jaroslav is also preparing patches on top of this it might make
> sense to get it into git sooner.
> 
> Reviewed-by: Mark Brown <broonie@kernel.org>

I'd like to get a comment from kselftest people about this addition
with the external alsa-lib.  Shua, what do you think?

If it's acceptable, I'd happily take the v2 patch and Sakamoto-san's
additional fix to sound.git tree.


> > As another topic, the runtime of alsa-lib application largely differs
> > between process user due to the result of parsing text files for
> > configuration space. I can easily imagine that developers unfamiliar to
> > alsa-lib carelessly adds invalid or inadequate configurations to files
> > under target path of alsa-lib configuration space, and they are puzzled
> > since they are unaware of the fact that the kselftest is affected by
> > userspace stuffs for the runtime.
> 
> > If we respect the basic theory of test (idempotence), we can use ioctl(2)
> > with requests for ALSA control interface since it's not so complicated
> > (at least it is easier than ALSA PCM interface). The purpose of
> > kselftest is to test kernel stuffs, not to test userspace stuffs
> > including alsa-lib implementation and variety of plugins.
> 
> Right, I was originally thinking of implementing this in terms of
> tinyalsa which is much more direct (though I was amused to see that's
> gained userspace plugins at some point!) partly for this reason but the
> lack of widespread packaging for it was a bit of a blocker and it didn't
> feel like a great idea to essentially do yet another userspace ALSA
> library even if as you say it can be pretty trivial.  Jaroslav's
> suggestion of using a custom configuration to override the default seems
> like it addresses everything though.
> 
> I do think there's an advantage for test comprehensibility in having the
> test written in terms of similar APIs to a normal userspace application
> - it makes it easier to relate what the test is doing to normal usage
> which is helpful when trying to understand what the test is trying to
> tell you.

This comes to the question again to the test with external libraries,
IMO.  If a self-contained test code is much preferred, we can go for
implementing open-code with raw kernel ABI.  The control API is
relatively simple and fairly solid over years, hence it's likely
feasible.  OTOH, using alsa-lib is also showing the test with the
actual use case, and in that sense, it's not bad at all as more
practical tests.


thanks,

Takashi