During the Linux 4.13 development cycle, the cciss driver has been
removed in favor of the hpsa driver, which has been amended with
some legacy board support.
* man4/cciss.4 (.SH DESCRIPTION): Mention driver removal.
* man4/hpsa.4 (.SH DESCRIPTION): Mention list of boards that are
recognised since Linux 4.13.
Signed-off-by: Eugene Syromyatnikov <evgsyr@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Drawn from Documentation/filesystems/sysfs.txt, P. Mochel's OLS
paper, and some naive investigation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Just a skeleton page so far, but perhaps it will be filled out
over time.
Reported-by: Mark Wielaard <mark@klomp.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
On a current x86-64 i7 system, sincos() is about 15% faster than
sin()+cos() according to the following test program.
/*
* Build with: cc -O -lm -fno-fast-math -fno-builtin
*/
int
main(int argc, char *argv[])
{
double arg, rsin, rcos;
int loop, i;
arg = strtod(argv[1], NULL);
loop = 10000000;
if (argc > 2)
loop = atoi(argv[2]);
if (argc > 3) {
printf("sin + cos\n");
for (i = 0; i < loop; i++) {
rsin = sin(arg);
rcos = cos(arg);
}
} else {
printf("sincos\n");
for (i = 0; i < loop; i++) {
sincos(arg, &rsin, &rcos);
}
}
}
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This accords with glibc headers and the Linux kernel source.
Reported-by: Fabio Scotoni <fabio@esse.ch>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Move the discussion of fsync() and metadata into a separate
paragraph to make the point more obvious.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Files crypt/sha{256,512}-crypt.c in the glibc source define
macros:
/* Default number of rounds if not explicitly specified. */
#define ROUNDS_DEFAULT 5000
/* Minimum number of rounds. */
#define ROUNDS_MIN 1000
/* Maximum number of rounds. */
#define ROUNDS_MAX 999999999
And the main encryption function __sha512_crypt_r() sets:
rounds = MAX (ROUNDS_MIN, MIN (srounds, ROUNDS_MAX));
One can check that for example
crypt("key", "$5$rounds=1$salt")
returns the string
$5$rounds=1000$salt$PWLKU7MTJ0s5M/mjBPcqnMsorm3qKyoBctxmZ1mNwn2
This parameter has been introduced in glibc 2.7.
Signed-off-by: Konstantin Shemyak <konstantin@shemyak.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In crypt/sha512-crypt.c::__sha512_crypt_r() and the similar
sha256 function, the length of the actually used salt is
calculated as:
salt_len = MIN (strcspn (salt, "$"), SALT_LEN_MAX);
Thus the trailing '$' is optional in the salt string. One can
check that
crypt("key", "$5$salt")
yields the same result as
crypt("key", "$5$salt$").
Signed-off-by: Konstantin Shemyak <konstantin@shemyak.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The encryption is done by glibc functions __shaxxx_crypt_r() in
files crypt/shaxxx-crypt.c. They implement a nontrivial algorithm
to construct the inputs for the hashing functions and to apply
them iteratively.
Signed-off-by: Konstantin Shemyak <konstantin@shemyak.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It would have been obvious that these limits are in bytes, except that
"ulimit -a" in at least bash, dash and zsh says that they're in blocks.
This confused me, so I had to check the kernel source code.
My understanding is that they are indeed in bytes, so mention this
information in the man page.
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This one is not very specific, as memory allocations are scattered across
the code, so let's put some generic description here.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk