Add documentation for the the PR_SET_TAGGED_ADDR_CTRL and
PR_GET_TAGGED_ADDR_CTRL prctls added in Linux 5.4 for arm64.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add documentation for the the PR_SVE_SET_VL and PR_SVE_GET_VL
prctls added in Linux 4.15 for arm64.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A patch has been merged for v5.8 that changes how syncfs() reports
errors. Change the sync() manpage accordingly.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The host ID might once have been intended to be globally unique,
but that turned out not to feasible.
Reported-by: Rich Felker <dalias@libc.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
If this was ever going to change the test case is very simple:
$ cd /tmp
$ touch libc.so.6
$ LD_LIBRARY_PATH=: sh
sh: error while loading shared libraries: libc.so.6: file too short
Signed-off-by: Arkadiusz Drabczyk <arkadiusz@drabczyk.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by mail from Geoff Clare, there are some details that
need correcting:
Subject: standards(7) (was: man-pages-5.07 released)
Date: Wed, 10 Jun 2020 10:53:14 +0100
From: Geoff Clare <gwc@opengroup.org>
...
The first isn't really a problem, just an oddity. You list
POSIX.1b as "formerly known as POSIX.4", but you don't do the
equivalent for POSIX.1c ("formerly known as POSIX.4a").
There are several problems with the XPG3 entry:
"first significant release" - although I suppose XPG3 could
be considered more significant than XPG2 because it was the
first one to incorporate POSIX.1, I don't think it's fair to
imply that XPG2 was not significant. (E.g. XPG2 was
significant in that it was the first release to include
I18N, and the first that had a conformance test suite.)
"produced by the X/Open Company, a multivendor consortium" -
this conflates two different things called X/Open. X/Open
Company Limited is the UK company that did the editing work,
organised meetings, etc. X/Open Group is the consortium
whose members developed the technical content.
"This multivolume guide was based on the POSIX standards" -
at the time there was only one POSIX standard, namely
POSIX.1-1988. The first release to incorporate POSIX.2 was
XPG4 (which you may consider worth noting in the XPG4
entry).
To fix these problems I would suggest changing the entry to:
XPG3 Released in 1989, this was the first release of the X/Open
Portability Guide to be based on a POSIX standard
(POSIX.1-1988). This multivolume guide was developed by the
X/Open Group, a multivendor consortium.
Under SUSv2 I would suggest changing:
Sometimes also referred to as XPG5.
to:
Sometimes also referred to (incorrectly) as XPG5.
Under POSIX.1-2001, SUSv3: "XSI conformance constitutes the Single
UNIX Specification version 3 (SUSv3)" is problematic. I think I
touched on this in the previous discussion. I would suggest
deleting that sentence and instead inserting, before "Two
Technical Corrigenda ...", the following:
The Single UNIX Specification version 3 (SUSv3) comprises the
Base Specifications containing XBD, XSH, XCU and XRAT as
above, plus X/Open Curses Issue 4 version 2 as an extra volume
that is not in POSIX.1-2001.
Something similar is needed in the POSIX.1-2008, SUSv4 entry where
it talks about "the same four parts". The extra volume this time
is X/Open Curses Issue 7.
]]
Cowritten-by: Geoff Clare <gwc@opengroup.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The fact that a more negative nice value means higher
priority is a continuing source of confusion.
Reported-by: Dan Kenigsberg <danken@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove superfluous paragraph macros.
Remove request ".br" if it precedes a line, that begins with a
space, as such lines automatically cause a break.
There is no change in the output from "nroff" and "groff".
###
Examples of warnings from "mandoc -Tlint":
mandoc: bindresvport.3:41:2: WARNING: skipping paragraph macro: PP after SH
mandoc: crypt.3:228:2: WARNING: skipping paragraph macro: PP empty
mandoc: dlinfo.3:151:2: WARNING: skipping paragraph macro: IP empty
mandoc: exec.3:86:2: WARNING: skipping paragraph macro: PP after SS
mandoc: getsubopt.3:45:2: WARNING: skipping paragraph macro: br before text line with leading blank
Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove superfluous paragraph macros.
Remove ".br" if it is before a line that starts with a space
character, as such lines automatically cause a break.
###
The output is unchanged, except two empty lines are added at the
bottom (before the footer line) in the output of "nroff" for the files
"alloc_hugepages.2" and "userfaultfd.2".
###
Examples of warnings from "mandoc -Tlint":
mandoc: access.2:283:2: WARNING: skipping paragraph macro: PP after SH
mandoc: adjtimex.2:185:2: WARNING: skipping paragraph macro: PP empty
mandoc: futex.2:728:2: WARNING: skipping paragraph macro: IP empty
mandoc: getsid.2:48:2: WARNING: skipping paragraph macro: br before text line with leading blank
mandoc: init_module.2:290:2: WARNING: skipping paragraph macro: PP after SS
mandoc: ioctl_fideduperange.2:27:2: WARNING: skipping paragraph macro: br after SH
Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Trim tailing space in "strings".
There is no change in the output from "nroff" and "groff".
###
Output is from: test-groff -b -mandoc -T utf8 -rF0 -t -w w -z
[ "test-groff" is a developmental version of "groff" ]
troff: <attributes.7>:510: warning: trailing space
troff: <attributes.7>:512: warning: trailing space
troff: <attributes.7>:513: warning: trailing space
troff: <attributes.7>:516: warning: trailing space
troff: <attributes.7>:649: warning: trailing space
troff: <attributes.7>:681: warning: trailing space
troff: <attributes.7>:720: warning: trailing space
####
troff: <environ.7>:181: warning: trailing space
troff: <environ.7>:182: warning: trailing space
####
troff: <ip.7>:820: warning: trailing space
####
troff: <signal.7>:316: warning: trailing space
Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
####
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Output is from: test-groff -b -mandoc -T utf8 -rF0 -t -w w -z
[ "test-groff" is a developmental version of "groff" ]
Input file is ./proc.5
troff: <proc.5>:4410: warning: trailing space
troff: <proc.5>:5206: warning: trailing space
troff: <proc.5>:5488: warning: trailing space
###
There is no change in the output from "nroff" and "groff".
Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Trim trailing space.
There is no change in the output from "nroff" and "groff".
Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
These links were mostly created when pages were moved between
sections, in almost every case several years ago. The idea
was to allow people time to get used to the new section numbers
while still having commands of the form "man <sec> <page>"
work as before. Let's assume that people have now had time to
get used to the new section numbers, and remove these links.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
These are all links that were created several years ago, mainly
when pages were migrated to different sections, in order to
allow the 'man' commands using the old section numbers to work.
However, the plan was always to eventually remove them, after
allowing people who cared to get used to the new section numbers.
Now, after 5+ years in each case, it's time to remove
these links.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Traditionally, magic links have not been a well-understood topic
in Linux. This helps clarify some of the terminology used in
openat2.2.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The variable is used in the code example, but not declared,
leading to a compilation error.
Signed-off-by: Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I believe new users should be discouraged from using atoi() and
that its disadvantages should be explained.
I added the information that 0 is returned on error - although C
standard and POSIX say that "If the value of the result cannot be
represented, the behavior is undefined." there are some
interpretations that 0 has to be returned
https://stackoverflow.com/questions/38393162/what-can-i-assume-about-the-behaviour-of-atoi-on-error
and this is also what happens in practice with glibc, musl and
uClibc.
Signed-off-by: Arkadiusz Drabczyk <arkadiusz@drabczyk.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
pgrep for example searches for a process name in /proc/pid/status
and therefore cannot find processes whose names are longer than 15
characters unless -f is specified.
Signed-off-by: Arkadiusz Drabczyk <arkadiusz@drabczyk.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reorder full wordings to match the order of abbreviations.
Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk