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

[Shuah Khan]

On 12/8/21 1:12 PM, Mark Brown wrote:
> On Wed, Dec 08, 2021 at 11:59:18AM -0700, Shuah Khan wrote:
>> On 12/8/21 11:39 AM, Mark Brown wrote:
>>> On Wed, Dec 08, 2021 at 10:42:35AM -0700, Shuah Khan wrote:
> 
>>>>> +	snd_ctl_elem_value_alloca(&val);
> 
>>> This is idiomatic for alsa-lib code.
> 
>> This is kernel code that is going into kernel sources. Why follow
>> alsa-lib convention?
> 
> Well, the kernel doesn't generally use alloca() as a pattern given the
> relatively small stack sizes we have and doesn't define helpers like
> these for it...  it's a toss up here between the conventions for use of
> the library we're using and the conventions of the kernel.
> 
>>>>> +	ksft_print_header();
> 
>>>> Add a check for root and skil the test.
> 
>>> There is no need for this test to run as root in most configurations,
>>> it is common to provide direct access to the sound cards to some or all
>>> users - for example with desktop distros the entire userspace audio
>>> subsystem normally runs as the logged in user by default.  alsa-lib's
> 
>> On my system, I don't see any output if run as root. Are there some tests
>> that work as non-root?
> 
> All of them work as non-root if the user they're running as has access
> to a card, if they do or not is system dependent - there may not be any
> cards at all in a given system to find.  Running as root will punch
> through most permission problems but it's not a requirement and a system
> could use a security module like SELinux to restrict what root can do.
> The sound devices are usually in /dev/snd, though userspace can place
> them where it wants - if run as a user that can access the relevant
> devices for the mixer interface (usually /dev/snd/controlC* though again
> userspace can rename them) then the tests will run on those devices.
> 

Sounds good to me.

Reviewed-by: Shuah Khan <skhan at linuxfoundation.org>

thanks,
-- Shuah