The current pages dumps all the content into one big DESCRIPTION
with no real visual break up between logically independent
sections. Add some subsection headers to make it easier to
read and scan.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
In Linux 4.8 (through a series of commits, 93e35efb8de45393c
being the actual reordering on x86), the order of
PTRACE_EVENT_SECCOMP and syscall-entry-stops was reversed.
Document both behaviors and their interaction with the
various forms of restart.
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
This fixes commit 51c612f (... Update FTM requirements
(_DEFAULT_SOURCE))
This commit updated numerous pages for the _SVID_SOURCE and
_BSD_SOURCE deprecations and the new use of _DEFAULT_SOURCE.
However during this conversion for setgroups(2), _BSD_SOURCE got
replaced by _SVID_SOURCE under the 'Glibc 2.19 and earlier:'
heading.
Put it back to _BSD_SOURCE. This was confirmed by building under
a Glibc 2.17 system and using _SVID_SOURCE resulted in a
warning: implicit declaration of function ‘setgroups’
[-Wimplicit-function-declaration]
message. Using _BSD_SOURCE gives a clean compile.
Signed-off-by: Andrew Clayton <andrew@digital-domain.net>
The word "very" here is overkill, and inclines the reader to
think that /dev/urandom is inferior.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text is a little confusing, since it somewhat
suggests that getrandom() "reads" from the /dev/random and
/dev/urandom devices. Rather, it is drawing from the same
pools as those devices. Reword the text to clarify that.
Plus a few other wording improvements.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Currently, recommendations on how to consume randomness are
spread across both getrandom(2) and random(4) and the general
opinion seems to be that the text in getrandom(2) does a
somewhat better job. Consolidate the discussion to a single
page (getrandom(2)) and address some of the concerns
expressed about the existing text in random(4).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The text currently states that O_NONBLOCK has no effect for
/dev/urandom, which is true. It also says that reads from
/dev/urandom are nonblocking. This is at the least confusing.
If one attempts large reads (say 10MB) from /dev/urandom
there is an appreciable delay, and interruption by a signal
handler will result in a short read. Amend the text to
reflect this.
Reviewed-by: Laurent Georget <laurent.georget@supelec.fr>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk