In OSSv4 these are supposed to avoid the wrapping problems with the
older GET(I|O)PTR ioctls but we don't quite get the same benefit here.
XXX: We could probably fake it by maintaining some state in-between calls.
One or two calls from this API were supported previously and have been
moved to the correct place.
Mapping the controls correctly is a difficult task. There is a define
hidden in the OSS headers that would allow an AUDIO_MIXER_SET control
to be represented perfectly, but it seems to _only_ exist there, and
no software supports it. So for now only one member of a set can be
set at a time - unfortunate. I've hidden code that should unlock
doing this the proper way under #notyet.
I'm not too happy with the way this code is managing file descriptors.
Currently it has to open a new fd for each ioctl due to OSSv4 deciding
to specify the device number in a structure rather than in the filename.
In the future, we could reuse the file descriptor if the correct one is
detected open.
This allows the mixer programs provided with the OSSv4 sources to compile
and work cleanly. I've observed problems with it failing to work on
secondary devices, and should investigate this later. There may be
a fd leak somewhere.
SNDCTL_DSP_COOKEDMODE simply always returns 1.
"Cooked mode" is a silly way the OSSv4 authors chose to refer to allowing
for reprocessed streams. The NetBSD kernel always performs format
conversion and it can't be turned off.
SNDCTL_DSP_GETERROR provides access to the read/write over/underrun
counters. There are other things it might return, but they don't make
sense for our implementation.
- Per OSSv4, make this ioctl work on the main mixer device.
Since the native NetBSD API uses queries on individual audio devices,
we have to reopen the correct audio device specified in the input to the
ioctl and fetch information from that.
- Correctly return whether the device is for playback, capture, or both.
- Return the full name of the device in the name field.
- The "handle" has to be a globally unique identifier. The closest thing
we have to that is device numbers, so use device numbers.
- Return reasonable values in min_rate/max_rate and min_channels/max_channels.
This should allow Mumble's device enumeration to work with a lot less
patching.
Combine the approach provided by Nikhil Benesch and Andrew Cagney.
Now, the unwinders (in gccgo, backtrace(3), etc) can unwind properly
the stack from a signal handler.
Fixes lib/55719 by Nikhil Benesch
and we were "slim" already)
Support for zic's long-obsolete '-y YEARISTYPE' option has been
removed and, with it, so has support for the TYPE field in Rule
lines, which is now reserved for compatibility with earlier zic.
These features were previously deprecated in release 2015f.
(Thanks to Tim Parenti.)
zic now defaults to '-b slim' instead of to '-b fat'.
zic's new '-l -' and '-p -' options uninstall any existing
localtime and posixrules files, respectively.
The undocumented and ineffective tzsetwall function has been
removed.
With help from skrll and pgoyette.
While here, change the example so it doesn't violate the advice just
given. Still not a great example -- abusing UINT_MAX for a reference
count is kinda sketchy, but it'll serve for now.
autoconf. Autoconf compiles simple programs like:
char symbol();
int main() { return symbol(); }
To check if the symbol is present. This makes it happy.
Another way our symbol renaming breaks things.
This fixes gdb native build, which does not find sigprocmask otherwise
and fails to build because it finds pthread_sigmask() and not sigprocmask()!
(where n is a decimal integer in the range [0 .. SIGRTMAX-SIGRTMIN].
As usual a leading "sig" is ignored and the strings are case independent.
Some implementations do not name the real time signals, and using
labels like RTMIN+3 can be the only way they can be manipulated,
so allow that technique (we still return the RTnn names on the inverse
translation though).
Because this is used by both kill(1) and sh(1) the kill and trap
commands both gain access to the new notation (when !SMALL).
Three ways to call:
getrandom(p, n, 0) Blocks at boot until full entropy.
Returns up to n bytes at p; guarantees
up to 256 bytes even if interrupted
after blocking. getrandom(0,0,0)
serves as an entropy barrier: return
only after system has full entropy.
getrandom(p, n, GRND_INSECURE) Never blocks. Guarantees up to 256
bytes even if interrupted. Equivalent
to /dev/urandom. Safe only after
successful getrandom(...,0),
getrandom(...,GRND_RANDOM), or read
from /dev/random.
getrandom(p, n, GRND_RANDOM) May block at any time. Returns up to n
bytes at p, but no guarantees about how
many -- may return as short as 1 byte.
Equivalent to /dev/random. Legacy.
Provided only for source compatibility
with Linux.
Can also use flags|GRND_NONBLOCK to fail with EWOULDBLOCK/EAGAIN
without producing any output instead of blocking.
- The combination GRND_INSECURE|GRND_NONBLOCK is the same as
GRND_INSECURE, since GRND_INSECURE never blocks anyway.
- The combinations GRND_INSECURE|GRND_RANDOM and
GRND_INSECURE|GRND_RANDOM|GRND_NONBLOCK are nonsensical and fail
with EINVAL.
As proposed on tech-userlevel, tech-crypto, tech-security, and
tech-kern, and subsequently adopted by core (minus the getentropy part
of the proposal, because other operating systems and participants in
the discussion couldn't come to an agreement about getentropy and
blocking semantics):
https://mail-index.netbsd.org/tech-userlevel/2020/05/02/msg012333.html
return that which poor behavior for the user, so return 0 instead.
We could document ~0 to be an error, but that would deviate from the
Linux behavior which is not desirable. Noted by Poul-Henning Kamp
When support for negative nrows/ncols was added, one s/ncols/maxx/ was
missed so we ended up passing negative (i.e. huge unsigned) length
when hashing the line contents.
Reported by Naman Jain in PR lib/55484
X/Open Curses says in the documentation for newpad():
Automatic refreshes of pads (e.g., from scrolling or echoing of
input) do not occur.
And in the documentation for get*():
If the current or specified window is not a pad, and it has been
moved or modified since the last refresh operation, then it will be
refreshed before another character is read.
From Michael Forney in PR lib/55457
Make default (wide) and non-wide behavior match. If the character
argument has (only) attributes set, use them with the default line
character.
In the wide case don't do the fallback in hline - it just calls
hline_set that needs to do it anyway. Fix the latter to check the
wcwidth of the right character and avoid division by zero.
Otherwise the ABSENT_NUMERIC(-1) or CANCELLED_NUMERIC(-2) will be converted
incorrectly to size_t and then down to uint16/32_t.
Picked up by DIAGNOSTIC builds.
Thanks to Michael Forney for the fix for PR lib/52293.
thread it is trying to awake. The thread could exit the condvar and then
reinsert itself at the head of the list with a new waiter behind it. It's
likely possible to fix this in a way that's wait-free but for now just fix
the bug.
Replace strncpy(3) with the safer strlcpy(3) and adjust the code.
Error was reported when build.sh was run with MKLIBCSANITIZER=yes flag.
Reviewed by: kamil@, christos@
pthread_t, so there's less chance of bad things happening if someone calls
(for example) pthread_cond_broadcast() from a signal handler.
- Remove all the deferred waiter handling except for the one case that really
matters which is transferring waiters from condvar -> mutex on wakeup, and
do that by splicing the condvar's waiters onto the mutex.
- Remove the mutex waiters bit as it's another complication that's not
strictly needed.
==> Provide a much more complete set of setters and getters for different
value types in the prop_array_util(3) and prop_dictionary_util(3)
functions.
==> Overhaul the prop_data(3), prop_number(3), and prop_string(3) APIs
to be easier to use and less awkwardly named, Deprecate the old
awkward names, and produce link-time warnings when they are referenced.
==> Deprecate mutable prop_data(3) and prop_string(3) objects. The old
APIs that support them still exist, but will now produce link-time
warnings when used.
==> When the new prop_string(3) API is used, strings are internally
de-duplicated as a memory footprint optimization.
==> Provide a rich set of bounds-checked gettter functions in and a
corresponding set of convenience setters in the prop_number(3) API.
==> Add a new prop_bool_value(3) function that is equivalent to
prop_bool_true(3), but aligned with the new "value" routines in
prop_data(3), prop_string(3), and prop_number(3).
Provide the hook from modern jemalloc to avoid using TSD for the thread
destruction cleanup as it can result in reentrancy crashes if fork is
called from a thread that never called malloc as it will result in a
late malloc from the pre-fork synchronisation handler.
timeouts or cancellation where:
- The restarting thread calls _lwp_exit() before another thread gets around
to waking it with _lwp_unpark(), leading to ESRCH (observed by joerg@).
(I may have removed a similar check mistakenly over the weekend.)
- The restarting thread considers itself gone off the sleep queue but
at the same time another thread is part way through waking it, and hasn't
fully completed that operation yet by setting thread->pt_mutexwait = 0.
I think that could have potentially lead to the list of waiters getting
messed up given the right circumstances.
It's established enough in non-legacy code that this is a terrible idea.
Even if we add getentropy it's not a comparable API (not a userspace RNG
capable of streaming large numbers of bytes, doesn't have _uniform, etc).
"Feel free to remove that line!" - riastradh
it aliased with. Assert that the alignment actually used reflects the
alignment required by existing implementation and for newly build
modules assert that it is at most the guaranteed alignment.
This is intended for 68060:
- GCC does not emit __muldi3() for 68020-40, that have 32 * 32 --> 64 mulul
- mulsl (and moveml), used in this code, are not implemented for 68010
In comparison with that from compiler_rt, this version saves:
- 12% of processing time
- 12 bytes of stack
- 50 bytes of code size
Also, slightly faster, memory saving, and smaller than libgcc version.
By examining with evcnt(9), __muldi3() is invoked more than 1000 times per
sec by kernel, which should justify to introduce assembler version of this
function.
- Switch to the C11-style atomic primitives using atomic_loadstore(9).
- npfkern: introduce the 'state.key.interface' and 'state.key.direction'
settings. Users can now choose whether the connection state should be
strictly per-interface or global at the configuration level. Keep NAT
logic to be always per-interface, though.
- npfkern: rewrite the G/C worker logic and make it self-tuning.
- npfkern and libnpf: multiple bug fixes; add param exporting; introduce
more parameters. Remove npf_nvlist_{copyin,copyout}() functions and
refactor npfctl_load_nvlist() with others; add npfctl_run_op() to have
a single entry point for operations. Introduce npf_flow_t and clean up
some code.
- npfctl: lots of fixes for the 'npfctl show' logic; make 'npfctl list'
more informative; misc usability improvements and more user-friendly
error messages.
- Amend and improve the manual pages.
