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@xxxxxxxxxx> 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
