Add a TNF copyright statement in t_mixerctl.sh

Compensate for changes made in mixerctl.c rev 1.29
Usage msg now appears on stderr, and causes exit status to be 1

Do the previous test a better way - for a file, test is generally
adequate, but for a device, we really need to actually try opening
it to determine that it is possible - so do the test that way, then
if the open succeeds once, assume it will the second time (which then
holds it open.)

Correct oversight in previous ... redirecting into a compound statement
causes the shell to exit if the redirect fails (posix says "may exit"
and /bin/sh does - maybe should give that more thought) - which will
happen if /dev/pad0 does not exist, causing a very messy test abort
(the shell running the test is not supposed to just go away). So
check tha the device exista and is readable before attempting to open it.

Problem brought to my attention by nat@ - thanks...

NFC: Typo in a comment corrected.

Make sure that the open of /dev/pad0 has succeeded (or at the very
least been attempted) before attempting to open /dev/mixer to determine
if the system being tested has audio or not. Leaving this for the background
cat command to do causes a race between that command and the parent sh.
Move this code to a helper function to avoid duplicating it.

Also avoid attempting to kill the background cat if it was never created.
The kill is likely unnecessary anyway, ATF seems to clean up processes
like that one without assistance. Which is a good thing, as the kill
does not happen if the test is skipped, or fails.

As pad devices are now created on demand - pad has to be open for a
corresponding mixer to be available.

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.

Drop the test for QEMU and instead skip relevant tests when /dev/mixer
can't be opened (which more accurately reflects when mixerctl is going
to fail...)

Based upon an idea from Andreas Gustafsson (gson@) - except that using
/dev/audio0 for this purpose doesn't work, if the only audio device
configured is pad0 an open of audio fails with EIO (???)

While here, perpare for the updated mixerctl coming soon to a repository
near you...
Use correct usage in the test of a bogus -d arg (otherwise the
new mixerctl will complain about usage, and never even
attempt to open the bogus device)
Don't require /dev/mixer for the noargs -> generate usage msg
test ... this will now generate a failing test with the
old mixerctl if there is no working /dev/mixer, but
that mixerctl won't be around much longer.

Limit previous to the i386 qemu kernels, the tests work on amd64 and sparc
(which have some audio configured.)

Skip most of the mixerctl tests when running under QEMU (assumed to be for ATF)
as the kernel that runs them has no audio (and no mixers) configured.

The usage message test might be returned some day if /usr/bin/mixerctl
gets modified so it doesn't attempt to open the device (and error out)
in cases where the device isn't actually going to be used (and -d wasn't
given to set the device name explicitly).

branches: 1.1.2; 1.1.4;
mixerctl tests from Charlotte Koch

Compensate for changes made in mixerctl.c rev 1.29
Usage msg now appears on stderr, and causes exit status to be 1

Do the previous test a better way - for a file, test is generally
adequate, but for a device, we really need to actually try opening
it to determine that it is possible - so do the test that way, then
if the open succeeds once, assume it will the second time (which then
holds it open.)

Correct oversight in previous ... redirecting into a compound statement
causes the shell to exit if the redirect fails (posix says "may exit"
and /bin/sh does - maybe should give that more thought) - which will
happen if /dev/pad0 does not exist, causing a very messy test abort
(the shell running the test is not supposed to just go away). So
check tha the device exista and is readable before attempting to open it.

Problem brought to my attention by nat@ - thanks...

NFC: Typo in a comment corrected.

Make sure that the open of /dev/pad0 has succeeded (or at the very
least been attempted) before attempting to open /dev/mixer to determine
if the system being tested has audio or not. Leaving this for the background
cat command to do causes a race between that command and the parent sh.
Move this code to a helper function to avoid duplicating it.

Also avoid attempting to kill the background cat if it was never created.
The kill is likely unnecessary anyway, ATF seems to clean up processes
like that one without assistance. Which is a good thing, as the kill
does not happen if the test is skipped, or fails.

As pad devices are now created on demand - pad has to be open for a
corresponding mixer to be available.

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.

Drop the test for QEMU and instead skip relevant tests when /dev/mixer
can't be opened (which more accurately reflects when mixerctl is going
to fail...)

Based upon an idea from Andreas Gustafsson (gson@) - except that using
/dev/audio0 for this purpose doesn't work, if the only audio device
configured is pad0 an open of audio fails with EIO (???)

While here, perpare for the updated mixerctl coming soon to a repository
near you...
Use correct usage in the test of a bogus -d arg (otherwise the
new mixerctl will complain about usage, and never even
attempt to open the bogus device)
Don't require /dev/mixer for the noargs -> generate usage msg
test ... this will now generate a failing test with the
old mixerctl if there is no working /dev/mixer, but
that mixerctl won't be around much longer.

Limit previous to the i386 qemu kernels, the tests work on amd64 and sparc
(which have some audio configured.)

Skip most of the mixerctl tests when running under QEMU (assumed to be for ATF)
as the kernel that runs them has no audio (and no mixers) configured.

The usage message test might be returned some day if /usr/bin/mixerctl
gets modified so it doesn't attempt to open the device (and error out)
in cases where the device isn't actually going to be used (and -d wasn't
given to set the device name explicitly).

branches: 1.1.2; 1.1.4;
mixerctl tests from Charlotte Koch

Do the previous test a better way - for a file, test is generally
adequate, but for a device, we really need to actually try opening
it to determine that it is possible - so do the test that way, then
if the open succeeds once, assume it will the second time (which then
holds it open.)

Correct oversight in previous ... redirecting into a compound statement
causes the shell to exit if the redirect fails (posix says "may exit"
and /bin/sh does - maybe should give that more thought) - which will
happen if /dev/pad0 does not exist, causing a very messy test abort
(the shell running the test is not supposed to just go away). So
check tha the device exista and is readable before attempting to open it.

Problem brought to my attention by nat@ - thanks...

NFC: Typo in a comment corrected.

Make sure that the open of /dev/pad0 has succeeded (or at the very
least been attempted) before attempting to open /dev/mixer to determine
if the system being tested has audio or not. Leaving this for the background
cat command to do causes a race between that command and the parent sh.
Move this code to a helper function to avoid duplicating it.

Also avoid attempting to kill the background cat if it was never created.
The kill is likely unnecessary anyway, ATF seems to clean up processes
like that one without assistance. Which is a good thing, as the kill
does not happen if the test is skipped, or fails.

As pad devices are now created on demand - pad has to be open for a
corresponding mixer to be available.

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.

Drop the test for QEMU and instead skip relevant tests when /dev/mixer
can't be opened (which more accurately reflects when mixerctl is going
to fail...)

Based upon an idea from Andreas Gustafsson (gson@) - except that using
/dev/audio0 for this purpose doesn't work, if the only audio device
configured is pad0 an open of audio fails with EIO (???)

While here, perpare for the updated mixerctl coming soon to a repository
near you...
Use correct usage in the test of a bogus -d arg (otherwise the
new mixerctl will complain about usage, and never even
attempt to open the bogus device)
Don't require /dev/mixer for the noargs -> generate usage msg
test ... this will now generate a failing test with the
old mixerctl if there is no working /dev/mixer, but
that mixerctl won't be around much longer.

Limit previous to the i386 qemu kernels, the tests work on amd64 and sparc
(which have some audio configured.)

Skip most of the mixerctl tests when running under QEMU (assumed to be for ATF)
as the kernel that runs them has no audio (and no mixers) configured.

The usage message test might be returned some day if /usr/bin/mixerctl
gets modified so it doesn't attempt to open the device (and error out)
in cases where the device isn't actually going to be used (and -d wasn't
given to set the device name explicitly).

branches: 1.1.2; 1.1.4;
mixerctl tests from Charlotte Koch

NFC: Typo in a comment corrected.

Make sure that the open of /dev/pad0 has succeeded (or at the very
least been attempted) before attempting to open /dev/mixer to determine
if the system being tested has audio or not. Leaving this for the background
cat command to do causes a race between that command and the parent sh.
Move this code to a helper function to avoid duplicating it.

Also avoid attempting to kill the background cat if it was never created.
The kill is likely unnecessary anyway, ATF seems to clean up processes
like that one without assistance. Which is a good thing, as the kill
does not happen if the test is skipped, or fails.

As pad devices are now created on demand - pad has to be open for a
corresponding mixer to be available.

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.

Drop the test for QEMU and instead skip relevant tests when /dev/mixer
can't be opened (which more accurately reflects when mixerctl is going
to fail...)

Based upon an idea from Andreas Gustafsson (gson@) - except that using
/dev/audio0 for this purpose doesn't work, if the only audio device
configured is pad0 an open of audio fails with EIO (???)

While here, perpare for the updated mixerctl coming soon to a repository
near you...
Use correct usage in the test of a bogus -d arg (otherwise the
new mixerctl will complain about usage, and never even
attempt to open the bogus device)
Don't require /dev/mixer for the noargs -> generate usage msg
test ... this will now generate a failing test with the
old mixerctl if there is no working /dev/mixer, but
that mixerctl won't be around much longer.

Limit previous to the i386 qemu kernels, the tests work on amd64 and sparc
(which have some audio configured.)

Skip most of the mixerctl tests when running under QEMU (assumed to be for ATF)
as the kernel that runs them has no audio (and no mixers) configured.

The usage message test might be returned some day if /usr/bin/mixerctl
gets modified so it doesn't attempt to open the device (and error out)
in cases where the device isn't actually going to be used (and -d wasn't
given to set the device name explicitly).

branches: 1.1.2; 1.1.4;
mixerctl tests from Charlotte Koch

As pad devices are now created on demand - pad has to be open for a
corresponding mixer to be available.

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.

Drop the test for QEMU and instead skip relevant tests when /dev/mixer
can't be opened (which more accurately reflects when mixerctl is going
to fail...)

Based upon an idea from Andreas Gustafsson (gson@) - except that using
/dev/audio0 for this purpose doesn't work, if the only audio device
configured is pad0 an open of audio fails with EIO (???)

While here, perpare for the updated mixerctl coming soon to a repository
near you...
Use correct usage in the test of a bogus -d arg (otherwise the
new mixerctl will complain about usage, and never even
attempt to open the bogus device)
Don't require /dev/mixer for the noargs -> generate usage msg
test ... this will now generate a failing test with the
old mixerctl if there is no working /dev/mixer, but
that mixerctl won't be around much longer.

Limit previous to the i386 qemu kernels, the tests work on amd64 and sparc
(which have some audio configured.)

Skip most of the mixerctl tests when running under QEMU (assumed to be for ATF)
as the kernel that runs them has no audio (and no mixers) configured.

The usage message test might be returned some day if /usr/bin/mixerctl
gets modified so it doesn't attempt to open the device (and error out)
in cases where the device isn't actually going to be used (and -d wasn't
given to set the device name explicitly).

branches: 1.1.2; 1.1.4;
mixerctl tests from Charlotte Koch

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.

Drop the test for QEMU and instead skip relevant tests when /dev/mixer
can't be opened (which more accurately reflects when mixerctl is going
to fail...)

Based upon an idea from Andreas Gustafsson (gson@) - except that using
/dev/audio0 for this purpose doesn't work, if the only audio device
configured is pad0 an open of audio fails with EIO (???)

While here, perpare for the updated mixerctl coming soon to a repository
near you...
Use correct usage in the test of a bogus -d arg (otherwise the
new mixerctl will complain about usage, and never even
attempt to open the bogus device)
Don't require /dev/mixer for the noargs -> generate usage msg
test ... this will now generate a failing test with the
old mixerctl if there is no working /dev/mixer, but
that mixerctl won't be around much longer.

Limit previous to the i386 qemu kernels, the tests work on amd64 and sparc
(which have some audio configured.)

Skip most of the mixerctl tests when running under QEMU (assumed to be for ATF)
as the kernel that runs them has no audio (and no mixers) configured.

The usage message test might be returned some day if /usr/bin/mixerctl
gets modified so it doesn't attempt to open the device (and error out)
in cases where the device isn't actually going to be used (and -d wasn't
given to set the device name explicitly).

branches: 1.1.2; 1.1.4;
mixerctl tests from Charlotte Koch

Drop the test for QEMU and instead skip relevant tests when /dev/mixer
can't be opened (which more accurately reflects when mixerctl is going
to fail...)

Based upon an idea from Andreas Gustafsson (gson@) - except that using
/dev/audio0 for this purpose doesn't work, if the only audio device
configured is pad0 an open of audio fails with EIO (???)

While here, perpare for the updated mixerctl coming soon to a repository
near you...
Use correct usage in the test of a bogus -d arg (otherwise the
new mixerctl will complain about usage, and never even
attempt to open the bogus device)
Don't require /dev/mixer for the noargs -> generate usage msg
test ... this will now generate a failing test with the
old mixerctl if there is no working /dev/mixer, but
that mixerctl won't be around much longer.

Limit previous to the i386 qemu kernels, the tests work on amd64 and sparc
(which have some audio configured.)

Skip most of the mixerctl tests when running under QEMU (assumed to be for ATF)
as the kernel that runs them has no audio (and no mixers) configured.

The usage message test might be returned some day if /usr/bin/mixerctl
gets modified so it doesn't attempt to open the device (and error out)
in cases where the device isn't actually going to be used (and -d wasn't
given to set the device name explicitly).

branches: 1.1.2;
mixerctl tests from Charlotte Koch

branches: 1.1.2;
mixerctl tests from Charlotte Koch