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.
Attachment:
signature.asc
Description: PGP signature
