clone.2, namespaces.7, pid_namespaces.7, user_namespaces.7: wfix "file system" ==> "filesystem"

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2014-03-14 19:54:00 +01:00
parent 85e34225be
commit ab3311aa06
4 changed files with 19 additions and 19 deletions

View File

@ -453,7 +453,7 @@ For security reasons,
.\" https://lwn.net/Articles/543273/
.\" The fix actually went into 3.9 and into 3.8.3. However, user namespaces
.\" were, for practical purposes, unusable in earlier 3.8.x because of the
.\" various file systems that didn't support userns.
.\" various filesystems that didn't support userns.
.BR CLONE_NEWUSER
cannot be specified in conjunction with
.BR CLONE_FS .

View File

@ -116,7 +116,7 @@ lrwxrwxrwx. 1 mtk mtk 0 Jan 14 01:20 uts -> uts:[4026531838]
Bind mounting (see
.BR mount (2))
one of the files in this directory
to somewhere else in the file system keeps
to somewhere else in the filesystem keeps
the corresponding namespace of the process specified by
.I pid
alive even if all processes currently in the namespace terminate.
@ -182,11 +182,11 @@ and (since Linux 2.6.30)
POSIX message queues (see
.BR mq_overview (7).
The common characteristic of these IPC mechanisms is that IPC
objects are identified by mechanisms other than file system
objects are identified by mechanisms other than filesystem
pathnames.
Each IPC namespace has its own set of System V IPC identifiers and
its own POSIX message queue file system.
its own POSIX message queue filesystem.
Objects created in an IPC namespace are visible to all other processes
that are members of that namespace,
but are not visible to processes in other IPC namespaces.
@ -252,9 +252,9 @@ option.
.\" ==================== Mount namespaces ====================
.\"
.SS Mount namespaces (CLONE_NEWNS)
Mount namespaces isolate the set of file system mount points,
Mount namespaces isolate the set of filesystem mount points,
meaning that processes in different mount namespaces can
have different views of the file system hierarchy.
have different views of the filesystem hierarchy.
The set of mounts in a mount namespace is modified using
.BR mount (2)
and
@ -263,13 +263,13 @@ and
The
.IR /proc/[pid]/mounts
file (present since Linux 2.4.19)
lists all the file systems currently mounted in the
lists all the filesystems currently mounted in the
process's mount namespace.
The format of this file is documented in
.BR fstab (5).
Since kernel version 2.6.15, this file is pollable:
after opening the file for reading, a change in this file
(i.e., a file system mount or unmount) causes
(i.e., a filesystem mount or unmount) causes
.BR select (2)
to mark the file descriptor as readable, and
.BR poll (2)
@ -300,14 +300,14 @@ The name of the mounted device
(or "nodevice" if there is no corresponding device).
.TP
(2)
The mount point within the file system tree.
The mount point within the filesystem tree.
.TP
(3)
The file system type.
The filesystem type.
.TP
(4)
Optional statistics and configuration information.
Currently (as at Linux 2.6.26), only NFS file systems export
Currently (as at Linux 2.6.26), only NFS filesystems export
information via this field.
.RE
.\"

View File

@ -225,7 +225,7 @@ the threads in a process can send signals to each other.
Similarly, it must be possible to see all of the threads
of a processes in the
.BR proc (5)
file system.
filesystem.
.IP *
.BR CLONE_SIGHAND
requires being in the same PID namespace;
@ -285,12 +285,12 @@ Thus, call sequences such as the following will fail (with the error
.SS /proc and PID namespaces
A
.I /proc
file system shows (in the
filesystem shows (in the
.I /proc/PID
directories) only processes visible in the PID namespace
of the process that performed the mount, even if the
.I /proc
file system is viewed from processes in other namespaces.
filesystem is viewed from processes in other namespaces.
After creating a new PID namespace,
it is useful for the child to change its root directory

View File

@ -442,7 +442,7 @@ One of the following is true:
The data written to
.I uid_map
.RI ( gid_map )
consists of a single line that maps the writing process's file system user ID
consists of a single line that maps the writing process's filesystem user ID
(group ID) in the parent user namespace to a user ID (group ID)
in the user namespace.
The usual case here is that this single line provides a mapping for user ID
@ -534,7 +534,7 @@ the set-user-ID (set-group-ID) bit is silently ignored:
the new program is executed,
but the process's effective user (group) ID is left unchanged.
(This mirrors the semantics of executing a set-user-ID or set-group-ID
program that resides on a file system that was mounted with the
program that resides on a filesystem that was mounted with the
.BR MS_NOSUID
flag, as described in
.BR mount (2).)
@ -570,9 +570,9 @@ the kernel.
When an unsupported subsystem is configured into the kernel,
it is not possible to configure user namespaces support.
As at Linux 3.8, most relevant subsystems support user namespaces,
but there are a number of file systems that do not.
but there are a number of filesystems that do not.
Linux 3.9 added user namespaces support for many of the remaining
unsupported file systems:
unsupported filesystems:
Plan 9 (9P), Andrew File System (AFS), Ceph, CIFS, CODA, NFS, and OCFS2.
XFS support for user namespaces is not yet available.
.\"
@ -644,7 +644,7 @@ CapEff: 0000001fffffffff
Mounting a new
.I /proc
file system and listing all of the processes visible
filesystem and listing all of the processes visible
in the new PID namespace shows that the shell can't see
any processes outside the PID namespace: