Most of the relevant discussion is now under /proc/PID/mounts;
all that needs to be here is a mention of the pre-2.4.19
system-wide namespace situation, and a reference to the
discussion under /proc/PID/mounts.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Describe per-process namespaces, including discussion
of clone() and unshare CLONE_NEWNS, and /proc/PID/mounts.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The length of this page means that it's becoming difficult to parse
which info is specific to mount() versus umount()/umount2(), so split
the umount material out into its own page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Refer the reader to new text in execve(2) that describes how
(since Linux 2.6.23) RLIMIT_STACK determines the value of ARG_MAX.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX.1-2001 says that the values returned by sysconf()
are constant for the life of the process.
But the fact that, since Linux 2.6.23, ARG_MAX is settable
via RLIMIT_STACK means _SC_ARG_MAX is no longer constant,
since it can change at each execve().
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Starting with Linux 2.6.23, the ARG_MAX limit became settable via
(1/4 of) RLIMIT_STACK. This broke ABI compatibility if RLIMIT_STACK
was set such that ARG_MAX was < 32 pages. Document the fact that
since 2.6.25 Linux imposes a floor on ARG_MAX, so that the old limit
of 32 pages is guaranteed.
For some background on the changes to ARG_MAX in kernels 2.6.23 and
2.6.25, see:
http://sourceware.org/bugzilla/show_bug.cgi?id=5786http://bugzilla.kernel.org/show_bug.cgi?id=10095http://thread.gmane.org/gmane.linux.kernel/646709/focus=648101,
checked into 2.6.25 as commit a64e715fc74b1a7dcc5944f848acc38b2c4d4ee2.
Also some reordering/rewording of the discussion of ARG_MAX.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The old sentence sat on its own in an odd place, and anyway the
modern BSDs use the name RLIMIT_NOFILE.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Include text describing semantics of fork() and execve() for
signal dispositions, signal mask, and pending signal set.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A sentence clarifying that pending signal set is union of
per-thread and process-wide pending signal sets.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The page was previously fuzzy about whether the these interfaces
have process-wide or per-thread semantics. (E.g., now the
page states that the calling *thread* (not process) is suspended
until the signal is delivered.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
These words are slightly bogus: although the interface is obsolete,
for ABI-compatibility reasons, the kernel folk should never be changing
this interface.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
glibc doesn't provide any support for readdir(2),
so remove these header files (which otherwirse suggest
that glibc does provide the required pieces).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The location of the fields fater d_name varies according to
the size of d_name. We can't properly declare them in C;
therefore, put those fields inside a comment.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The structure isn't currently defined in glibc headers, and the kernel
name of the structure is 'linux_dirent' (as was already used in some,
but not all, places in this page).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk