b5 audio tests sometimes being skipped (seemingly randomly)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

I have noticed that some of the mixerctl ATF tests run on babylon5
occasionally skip - they will work in one run, and not in another
(at least on i386 and amd64 - does the emulated sparc system have some
kind of emulated audio other than pad, or none at all, including pad ?)

The code that does this is (from the tests/usr.bin/mixerctl/t_mixerctl nflag
test) is (was)

        cat /dev/pad0 > /dev/null 2>&1 &
        padpid=$!

        (</dev/mixer) >/dev/null 2>&1 ||
            atf_skip "no audio mixer available in kernel"

For the skip to happen, the open of /dev/mixer must fail.   That
should always work, as the pad0 audio device is supposed to be
available for it to use (or if there was no pad0 it should always
fail) - that's what the cat just before it is setting up.

What I think might be happening, is that the shell creates the cat
process, then goes on and attempts to open /dev/mixer before cat actually
gets a chance to open /dev/pad0 - sometimes - it will all depend upon
timing.

So, I have changed the test in a way that the shell does the open of
/dev/pad0 before it starts the background cat - that way we know the
open must have happened (if it is going to work - it doesn't matter if
it fails on systems with real audio hardware) before we get to attempting
to open the mixer.

I have also refactored the code to do this in a common routine, rather than
copying the same code into every test, and slightly changed the final kill so
it isn't attempted if the cat process was never created.  Note that that kill
is most likely not needed at all - I believe that ATF does a killpg() to
kill any processes that may have been left running (good thing too, as if a
test fails, or is skipped, the kill in the test never happens - and moving it
to a cleanup function is messy, as there are no shared variables, the pid would
need to be written to a file insstead ... I did try doing that, but the cat
process was never still existing by the time the cleanup function was called,
so I dropped that idea.)

This all works when run on real hardware (well, a Xen DomU, with pad0 audio)
now just have to wait and see if it makes the tests on b5 more consistent.

kre