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

From: Mark Brown <broonie@kernel.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Takashi Iwai <tiwai@suse.de>, Shuah Khan <shuah@kernel.org>,
	Jaroslav Kysela <perex@perex.cz>,
	linux-kselftest@vger.kernel.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH v2] kselftest: alsa: Add simplistic test for ALSA mixer controls kselftest
Date: Wed, 8 Dec 2021 20:12:19 +0000	[thread overview]
Message-ID: <YbERo5FxA6Rm3bhd@sirena.org.uk> (raw)
In-Reply-To: <37f87d39-b5a9-46f6-2667-c0b7aafb731a@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]