into two parts so that some of the routines could be used by rump.
Now that rump uses both vfs_subr and vfs_subr2 and there is no
reason to keep two files lying around, re-unite them.
sensitive information in memory longer than necessary
(We could make this depend on ~ECHO or so, but this would be an API
change and I don't think it is worth the effort.)
-use AUMODE_PLAY_ALL, from Sergey Svishchev -- this might cause
stuttering if the write to audio can't keep up, but it avoids pauses
if the audio buffer drains out on stop/resume
-The timeout for the raw SCSI command to read audio data
was too small, causing complete failure for me.
-Since the itimer can't do faster than HZ, a too small buffer doesn't
work. Try to calculate a sensible buffer size.
-While it makes sense to deliver data a bit faster than necessary,
it should be not that much that the blocking in the signal handler
hurts interactive response. Allow for 50ms.
-Comment out a sched_yield() in the signal handler - this doesn't
look right.
This is far from being perfect, but it makes digital mode usable for me.
And for Jeremy C. Reed, the author of PR bin/38493.
Why is there a "Makefile.boot" used here, and a "Makefile.booters"
used one level up, with redundant stuff between both of them? This all
used to be so clean...
For now, we include kernel revision as a way of allowing users to
notice that boot blocks have gotten very old, so the first line of the
printout looks like this (depending on the particular block):
>> NetBSD/x86 BIOS Boot, Revision 3.4 (from NetBSD 5.0)
This may be changed a bit pending feedback. (Some people think that
the kernel revision shouldn't be there at all, for example.)
Part of the project to assure that bit-identical sources produce
bit-identical release binaries.
That helps me get rid of some conditional compilation (INET6) in
ifconfig.
Let each protocol/feature-module print its own usage, so that the
ifconfig usage reflects the modules that are actually compiled-in.
Write usage information for carp(4) options.
const char bootprog_kernrev[] = "4.99.70";
For now, we still also include the builder name and date and such, so
that we don't break anything, but those are (probably) on the way out.
Part of the "bit-identical sources yield bit-identical release files"
project.
