I'd say this is fair use (many other man pages do the same).
So, no need to clutter the man page source with this information.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This is my writeup of a basic description of /dev/fuse after
playing with it for a few hours today. It is of course woefully
incomplete, and since I neither have a use case nor am working
on this code, I will not be in a position to expand it in the
near future. However, I'm hoping this could still serve as a
handy reference for others looking at this interface.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
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>
Make the information easier to parse by formatting the file
descriptions as hanging lists. No significant content changes.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This documents the "property" of /dev/urandom of being able to
serve numbers prior to pool being initialized, and removes any
suggested usages of /dev/random which are disputable
(i.e., one-time pad). Document the fact /dev/random is only
suitable for applications which can afford indeterminate delays
since very few applications can do so. Smooth the alarming
language about a theoretical attack, and mention that its
security depends on the cryptographic primitives used by the
kernel, as well as the total entropy gathered.
Reviewed-by: Laurent Georget <laurent@lgeorget.eu>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
In addition to the already documented keyboard modes (K_RAW, K_XLATE,
K_MEDIUMRAW, and K_UNICODE) there is also K_OFF one, defined for
KDGKBMODE and KDSKBMODE ioctl requests in <linux/kd.h>.
As reported by Chris:i
The manual entry for KDGETMODE specifies "argp points to
a long which is set to one of the above values." At least
on x86_64-bit Fedora24, the text should probably specify
argp is an int (32-bit), rather than a long (64-bit).
[To verify:]
Open a file descriptor to the local console, and execute
some code like the following:
long arg = -1;
if (-1 == ioctl(fd, KDGETMODE, &arg)) { return -1; }
printf("KDGETMODE: 0x%lx\n", arg);
Now try this version:
int arg = -1;
if (-1 == ioctl(fd, KDGETMODE, &arg)) { return -1; }
printf("KDGETMODE: 0x%x\n", arg);
Result:
The first version gives this result:
KDGETMODE: 0xffffffff00000001
The second version gives this result:
KDGETMODE: 0x1
Reading the kernel source confirms this point.
Reported-by: Chris Gassib <position0x45@hotmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Update the description of the MTMKPART operation of MTIOCTOP to match
the changes in kernel version 4.6 (commit
8038e6456a3e6f5c4759e0d73c4f9165b90c93e7)
Signed-off-by: Kai Mäkisara <kai.makisara@kolumbus.fi>
Fix the description of read() in variable block mode if the next
block is larger than the requested byte count: error is returned
(as already documented with ENOMEM; better to complete the change
later than never ?-)
Signed-off-by: Kai Mäkisara <kai.makisara@kolumbus.fi>
Hi Michael,
0f9e647 removed the obsolete console(4) page but we still have few
references to it. The patch below removes them or converts to refs
to concole_ioctl(4) where appropriate.
The lirc.h header has landed in the kernel, and the kernel docs
has been updated all of which reflected in this patch.
Here is still an open issue with duplicated info in the kernel
docs and the manpage. Eventually, this should be addressed but
I frankly don't know how. In the meantime, acknowledge the fact
that the kernel docs is the ultimate source
Michael Kerrisk