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

[Mark Brown]

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 at kernel.org>

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20211207/c0111bb1/attachment.sig>