tzset(3) currently states that there are three TZ formats. The
first two it lists are actually variations of the POSIX-style
TZ format, of which there are at least five variations.
This patch corrects this to match the POSIX specification of
TZ having only two formats.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The TZ string representation indicates that the start/end
rules are required; this is incorrect.
Updated the TZ string format to the POSIX specification and
improve its readability by having only the optional parts in
italics.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add a reference to the AF_ALG protocol accessible via socket(2).
Signed-off-by: Stephan Mueller <stephan.mueller@atsec.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Based upon reviewing the glibc source, the posixrules file is being used
for very specific TZ strings that can be represented as:
[:]stdoffsetdst[offset][,]
If anything follows the above string, even invalid data, posixrules will
not be used. Below is some shell output demonstrating this.
$ TZ="NZST-12:00:00NZDT-13:00:00,ANYTHING" \
strace -eopen date 2>&1 | grep -Ei 'posixrules|jan'
Thu Jan 29 06:53:35 NZDT 2015
$ TZ="NZST-12:00:00NZDT-13:00:00," \
strace -eopen date 2>&1 | grep -Ei 'posixrules|jan'
open("/usr/share/zoneinfo/posixrules", O_RDONLY|O_CLOEXEC) = 3
Thu Jan 29 05:54:58 NZST 2015
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
FILES section was overly verbose and included
environment variables. Added ENVIRONMENT section,
removing ENV VARS from the FILES section.
As stated in commit 2c7f200, /usr/share/zoneinfo/localtime
is not used, nor recommended by glibc.
Signed-off-by: J William Piggott <elseifthen@gmx.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
With his last patches for getrandom.2 Michael Kerrisk posed a few
questions and left some comments in the man-page. This patch
seeks to clarify the open issues.
72 For example, if the call is interrupted by a signal handler,
73 it may return a partially filled buffer, or fail with the error
74 .BR EINTR .
75 .\" Tested with buffer sizes > 256 bytes: both partial reads
76 .\" and EINTR can occur, with the former being more frequent.
77 .\"
Michael's observation agrees with the code.
For buffer size > 256: If the buffer is still empty EINTR occurs.
If any number of bytes has been read to the buffer, that number
is returned. The comment can be removed.
78 .\" mtk: In the absence of signals, in my testing, even very large reads
79 .\" return full buffers. I found that reads of up to 33554431 always
80 .\" returned a filled buffer. Specifying 'buflen' > 33554431 always
81 .\" returned just 33554431 bytes. (I'm not sure where that number comes
from.
The maximum number of bytes transferred is limited for
/dev/urandom to:
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
// <= 0x1fffff
and for /dev/random to
nbytes = min_t(size_t, nbytes, SEC_XFER_SIZE); // <= 0x200
Lets put this into the NOTES section.
224 When reading from
225 .IR /dev/random ,
226 blocking requests of any size can be interrupted by a signal
227 (the call fails with the error
228 .BR EINTR ).
Thats ok.
82 If the pool has not yet been initialized, then the call blocks, unless
83 .B GRND_RANDOM
84 is specified in
85 .IR flags .
86 .\" FIXME We need a bit more information here.
87 .\" The reader will ask: when is /dev/urandom initialized?
88 .\" There should be some text here to explain that.
Entropy is collected from different sources, e.g.
- time of reaping a thread
- MAC address of a network interfaces
- Allwinner security ID
- ROM content of a firewire device
- ...
When more than 128 bits have been collected, the pool is set
to initialized.
I suggest that detailed information about the initialization
should be provided on the random.4 page.
I added a paragraph in the NOTES section.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The patch clarifies when blocking may occur while calling
getrandom().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Theodore Ts'o confirmed the bug described in
https://lkml.org/lkml/2014/11/29/16
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Kernel 3.17 introduces a new system call getrandom(2).
The man page in this patch is based on the commit message by
Theodore Ts'o and suggestions by Michael Kerrisk.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk