kre dfcb546256 If we are using the pad audio device, there must be a process with
the corresponding pad device open, or we get EIO from audio accesses

Explained and fix provided by Nathanial Sloss <nat@n.o>

Note: if we are testing and using real audio hardware, the open
of /dev/pad0 is irrelevant (but harmless, so we don't attempt to
check) and what's more it doesn't matter if it succeeds or fails.

If we're testing under qemu (or any other situation where the only
audio "hardware" is pad) then the open will work, and there should be
no more EIO.

If there is no audio hardware of any kind on the system being tested,
the attempt top open /dev/mixer should fail, and the test will be
skipped.
2017-04-20 00:17:11 +00:00
..
2017-01-14 01:33:32 +00:00

$NetBSD: README,v 1.4 2012/05/18 15:36:21 jruoho Exp $

When adding new tests, please try to follow the following conventions.

1. For library routines, including system calls, the directory structure of
   the tests should follow the directory structure of the real source tree.
   For instance, interfaces available via the C library should follow:

	src/lib/libc/gen -> src/tests/lib/libc/gen
	src/lib/libc/sys -> src/tests/lib/libc/sys
	...

2. Equivalently, all tests for userland utilities should try to follow their
   location in the source tree. If this can not be satisfied, the tests for
   a utility should be located under the directory to which the utility is
   installed. Thus, a test for env(1) should go to src/tests/usr.bin/env.
   Likewise, a test for tcpdump(8) should be in src/tests/usr.sbin/tcpdump,
   even though the source code for the program is located under src/external.

3. Otherwise use your own discretion.