This was introduced two years ago when the getrandom/getentropy API
question was still open, and removed because the discussion was
ongoing. Now getentropy is more widely adopted and soon to be in
POSIX. So reintroduce the symbol into libc since we'll be keeping it
anyway. Discussion of details of the semantics, as interpreted by
NetBSD, is ongoing, but the symbol needs to get in before the
netbsd-10 branch. The draft POSIX text is
(https://www.opengroup.org/austin/docs/austin_1110.pdf):
SYNOPSIS
#include <unistd.h>
int getentropy(void *buffer, size_t length);
DESCRIPTION
The getentropy() function shall write length bytes of data
starting at the location pointed to by buffer. The output
shall be unpredictable high quality random data, generated by
a cryptographically secure pseudo-random number
generator. The maximum permitted value for the length
argument is given by the {GETENTROPY_MAX} symbolic constant
defined in <limits.h>.
RETURN VALUES
Upon successful completion, getentropy() shall return 0;
otherwise, -1 shall be retunred and errno set to indicate the
error.
ERRORS
The getentropy() function shall fail if:
[EINVAL] The value of length is greater than
{GETENTROPY_MAX}.
The getentropy() function may fail if:
[ENOSYS] The system does not provide the necessary
source of entropy.
RATIONALE
The getentropy() function is not a cancellation point.
Minor changes from the previous introduction of getentropy into libc:
- Return EINVAL, not EIO, on buflen > 256.
- Define GETENTROPY_MAX in limits.h.
The declaration of getentropy in unistd.h and definition of
GETENTROPY_MAX in limits.h are currently conditional on
_NETBSD_SOURCE. When the next revision of POSIX is finalized, we can
expose them also under _POSIX_C_SOURCE > 20yymmL as usual -- and this
can be done as a pullup without breaking existing compiled programs.
command, so that the command cannot appear to be more options
(which always then fails, as there would be no arg for "-c" to
treat as the command string in that case).
For the full (LONG) explanation, see:
http://mail-index.netbsd.org/current-users/2021/10/29/msg041629.html
(Currently it depends on the underlying directory, but documenting the
exact details seems inadvisable.)
Also, Someone(TM) should check if POSIX permits this or if we ought to
improve the implementation.
(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).
- lock all relevant mutexes just before fork
- unlock all mutexes just after fork in the parent
- full reinit non-spinlocks in the child
This is not using the normal pthread_atfork interface to ensure order of
operation, malloc is used as implementation detail too often.
riastradh