古いシステムでは、 \fBsetrlimit\fP() と同様の目的を持つ関数 \fBvlimit\fP() が提供されていた。 後方互換性のため、glibc
でも \fBvlimit\fP() を提供している。 全ての新しいアプリケーションでは、 \fBsetrlimit\fP() を使用すべきである。
.SS "C ライブラリとカーネル ABI の違い"
-Since version 2.13, the glibc \fBgetrlimit\fP() and \fBsetrlimit\fP() wrapper
-functions no longer invoke the corresponding system calls, but instead
-employ \fBprlimit\fP(), for the reasons described in BUGS.
+バージョン 2.13 以降では、 glibc の \fBgetrlimit\fP() と \fBsetrlimit\fP()
+のラッパー関数はもはや対応するシステムコールを呼び出さず、 代わりに「バグ」の節で説明されている理由から \fBprlimit\fP() を利用している。
.SH バグ
以前の Linux カーネルでは、プロセスがソフトまたはハード \fBRLIMIT_CPU\fP リミットに達した場合に送られる \fBSIGXCPU\fP と
\fBSIGKILL\fP シグナルが、本来送られるべき時点の 1 (CPU) 秒後に送られてしまう。 これはカーネル 2.6.8 で修正された。
.\"
2.4.22 より前のカーネルでは、 \fIrlim\->rlim_cur\fP が \fIrlim\->rlim_max\fP より大きかった場合、
\fBsetrlimit\fP() での \fBEINVAL\fP エラーを検出できない。
-.SS "Representation of \(dqlarge\(dq resource limit values on 32\-bit platforms"
+.SS "32 ビットプラットフォームにおける「大きな」リソース上限値の表現"
.\" https://bugzilla.kernel.org/show_bug.cgi?id=5042
.\" http://sources.redhat.com/bugzilla/show_bug.cgi?id=12201
-The glibc \fBgetrlimit\fP() and \fBsetrlimit\fP() wrapper functions use a 64\-bit
-\fIrlim_t\fP data type, even on 32\-bit platforms. However, the \fIrlim_t\fP data
-type used in the \fBgetrlimit\fP() and \fBsetrlimit\fP() system calls is a
-(32\-bit) \fIunsigned long\fP. Furthermore, in Linux versions before 2.6.36,
-the kernel represents resource limits on 32\-bit platforms as \fIunsigned
-long\fP. However, a 32\-bit data type is not wide enough. The most pertinent
-limit here is \fBRLIMIT_FSIZE\fP, which specifies the maximum size to which a
-file can grow: to be useful, this limit must be represented using a type
-that is as wide as the type used to represent file offsets\(emthat is, as
-wide as a 64\-bit \fBoff_t\fP (assuming a program compiled with
-\fI_FILE_OFFSET_BITS=64\fP).
-
-To work around this kernel limitation, if a program tried to set a resource
-limit to a value larger than can be represented in a 32\-bit \fIunsigned
-long\fP, then the glibc \fBsetrlimit\fP() wrapper function silently converted
-the limit value to \fBRLIM_INFINITY\fP. In other words, the requested resource
-limit setting was silently ignored.
-
-This problem was addressed in Linux 2.6.36 with two principal changes:
+glibc の \fBgetrlimit\fP() と \fBsetrlimit\fP() ラッパー関数は、32 ビットプラットフォームであっても 64 ビットの
+\fIrlim_t\fP データ型を使用する。 しかし、 \fBgetrlimit\fP() と \fBsetrlimit\fP() システムコールで使用される
+\fIrlim_t\fP データ型は (32 ビットの) \fIunsigned long\fP である。 さらに、 2.6.36 より前の Linux では、
+カーネルは 32 ビットプラットフォームではリソース上限を \fIunsigned long\fP として表現している。 しかしながら、 32
+ビットデータ型は十分な大きさではない。 ここで最も関係がある上限値は \fBRLIMIT_FSIZE\fP である。
+この上限はファイルサイズの最大値であり、実用性の面からは、 この上限をファイルオフセットを表現するのに使用されている型、 つまり 64 ビットの
+\fBoff_t\fP (\fI_FILE_OFFSET_BITS=64\fP でコンパイルしたプログラムの場合)、 と同じ幅を持つ型、を使って表現すべきである。
+
+カーネルのこの制限に対する対策として、 プログラムがリソース上限を 32 ビットの \fIunsigned long\fP
+で表現できる値よりも大きな値に設定しようとした際には、 glibc の \fBsetrlimit\fP() ラッパー関数はこの上限値を黙って
+\fBRLIM_INFINITY\fP に変換していた。 言い換えると、指定されたリソース上限値は黙って無視されていた。
+
+この問題は Linux 2.6.36 での以下の主な変更により解決された。
.IP * 3
-the addition of a new kernel representation of resource limits that uses 64
-bits, even on 32\-bit platforms;
+32 ビットプラットフォームであっても 64 ビットを使用するリソース上限の新しいカーネルでの表現方法の追加。
.IP *
-the addition of the \fBprlimit\fP() system call, which employs 64\-bit values
-for its resource limit arguments.
+リソース上限の引き数として 64 ビット値を取る \fBprlimit\fP() システムコールの追加。
.PP
.\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201
-Since version 2.13, glibc works around the limitations of the \fBgetrlimit\fP()
-and \fBsetrlimit\fP() system calls by implementing \fBsetrlimit\fP() and
-\fBgetrlimit\fP() as wrapper functions that call \fBprlimit\fP().
+バージョン 2.13 以降の glibc では、 \fBgetrlimit\fP() と \fBsetrlimit\fP()
+システムコールの制限に対する回避手段として、
+\fBsetrlimit\fP() と \fBgetrlimit\fP() を \fBprlimit\fP() を呼び出すラッパー関数として実装している。
.SH 例
以下のプログラムに \fBprlimit\fP() の使用例を示す。
.PP
を使うとこのデフォルトを変更することができる。 ファイルオフセット
(file offset) はファイルの先頭に設定される (\fBlseek\fP(2) 参照)。
.PP
-A call to \fBopen\fP() creates a new \fIopen file description\fP, an entry in the
-system\-wide table of open files. The open file description records the file
-offset and the file status flags (see below). A file descriptor is a
-reference to an open file description; this reference is unaffected if
-\fIpathname\fP is subsequently removed or modified to refer to a different
-file. For further details on open file descriptions, see NOTES.
+\fBopen\fP() を呼び出すと、「オープンファイル記述」 \fI(open file description)\fP
+が作成される。ファイル記述とは、システム全体のオープン中のファイルのテーブルのエントリである。
+このオープンファイル記述は、ファイルオフセットとファイル状態フラグ (下記参照) が保持する。
+ファイルディスクリプタはオープンファイルっ記述への参照である。 この後で \fIpathname\fP
+が削除されたり、他のファイルを参照するように変更されたりしても、 この参照は影響を受けない。 オープンファイル記述の詳細な説明は「注意」の節を参照。
.PP
引き数 \fIflags\fP には、アクセスモード \fBO_RDONLY\fP, \fBO_WRONLY\fP, \fBO_RDWR\fP
のどれかひとつが入っていなければならない。 これらはそれぞれ読み込み専用、書き込み専用、読み書き用に ファイルをオープンすることを要求するものである。
\fBfcntl\fP(2) の \fBF_GETFL\fP 操作を使ったオープンされたファイルの状態フラグの取得。 返されるフラグには \fBO_PATH\fP
ビットが含まれる。
.IP *
-Passing the file descriptor as the \fIdirfd\fP argument of \fBopenat\fP(2) and
-the other "*at()" system calls. This includes \fBlinkat\fP(2) with
-\fBAT_EMPTY_PATH\fP (or via procfs using \fBAT_SYMLINK_FOLLOW\fP) even if the
-file is not a directory.
+\fBopenat\fP(2) や他の "*at()" 系のシステムコールの \fIdirfd\fP 引数としてそのファイルディスクリプタを渡す。 これには、
+ファイルがディレクトリでない場合に \fBlinkat\fP(2) に \fBAT_EMPTY_PATH\fP が指定された場合 (や procfs 経由で
+\fBAT_SYMLINK_FOLLOW\fP が使用された場合) を含む。
.IP *
そのファイルディスクリプタを別のプロセスに UNIX ドメインソケット経由で渡す。 (\fBunix\fP(7) の \fBSCM_RIGHTS\fP を参照)
.RE
\fIst_ctime\fP と \fIst_mtime\fP も現在時刻に設定される。 それ以外の場合で、O_TRUNC フラグでファイルが修正されたときは、
ファイルの \fIst_ctime\fP と \fIst_mtime\fP フィールドが現在時刻に設定される。
.SS オープンファイル記述
-The term open file description is the one used by POSIX to refer to the
-entries in the system\-wide table of open files. In other contexts, this
-object is variously also called an "open file object", a "file handle", an
-"open file table entry", or\(emin kernel\-developer parlance\(ema \fIstruct
-file\fP.
-
-When a file descriptor is duplicated (using \fBdup\fP(2) or similar), the
-duplicate refers to the same open file description as the original file
-descriptor, and the two file descriptors consequently share the file offset
-and file status flags. Such sharing can also occur between processes: a
-child process created via \fBfork\fP(2) inherits duplicates of its parent's
-file descriptors, and those duplicates refer to the same open file
-descriptions.
+オープンファイル記述という用語は POSIX
+で使用されている用語で、オープンされているファイルのシステム共通のテーブルのエントリーを参照するものである。
+別の文脈では、このオブジェクトはいろいろな呼び方があり、
+「オープンファイルオブジェクト」、「ファイルハンドル」、「オープンファイルテーブルエントリー」、 カーネル開発者の用語では \fIstruct file\fP
+などと呼ばれる。
+
+ファイルディスクリプタが (\fBdup\fP(2) や同様のシステムコールを使って) 複製される際に、
+複製されたファイルディスクリプタは元のファイルディスクリプタと同じオープンファイル記述を参照する。 結果として 2
+つのファイルディスクリプタはファイルオフセットとファイル状態フラグを共有する。 このような共有はプロセス間でも起こり得る。 \fBfork\fP(2)
+で作成された子プロセスは親プロセスのファイルディスクリプタの複製を継承し、これらの複製は同じオープンファイル記述を参照する。
.\"
.\"
-Each \fBopen\fP(2) of a file creates a new open file description; thus, there
-may be multiple open file descriptions corresponding to a file inode.
+1 つのファイルに対して \fBopen\fP(2) を行う毎に、新しいオープンファイル記述が作成される。 したがって、 1 つのファイル inode
+に対して複数のオープンファイル記述が存在することがありえる。
.SS "同期 I/O"
POSIX.1\-2008 の「同期 I/O」の選択肢として複数種類が規定されており、 動作を制御するために \fBopen\fP() フラグとして
\fBO_SYNC\fP, \fBO_DSYNC\fP, \fBO_RSYNC\fP が規定されている。 この選択肢を実装がサポートしているかに関わらず、
\fBunlinkat\fP(2), \fButimensat\fP(2) \fBmkfifoat\fP(3), \fBscandirat\fP(3))
は二つの理由から用意されている。 ここでは、 \fBopenat\fP コールに関して説明するが、この基本原理は他のインターフェースでも同じである。
-First, \fBopenat\fP() allows an application to avoid race conditions that
-could occur when using \fBopen\fP() to open files in directories other than
-the current working directory. These race conditions result from the fact
-that some component of the directory prefix given to \fBopen\fP() could be
-changed in parallel with the call to \fBopen\fP(). Suppose, for example, that
-we wish to create the file \fIpath/to/xxx.dep\fP if the file \fIpath/to/xxx\fP
-exists. The problem is that between the existence check and the file
-creation step, \fIpath\fP or \fIto\fP (which might be symbolic links) could be
-modified to point to a different location. Such races can be avoided by
-opening a file descriptor for the target directory, and then specifying that
-file descriptor as the \fIdirfd\fP argument of (say) \fBfstatat\fP(2) and
-\fBopenat\fP().
+最初の理由として、 \fBopenat\fP() を使うと、 アプリケーションは、 カレントワーキングディレクトリ以外のディレクトリで \fBopen\fP()
+を使ってファイルをオープンする際に起こり得る競合条件を避けることができる。 これらの競合条件は、 \fBopen\fP()
+に渡されたディレクトリプレフィックスの構成要素が \fBopen\fP() の呼び出しと並行して変化する可能性があるという点に由来している。 例えば、ファイル
+\fIpath/to/xxx\fP が存在する場合にファイル \fIpath/to/xxx.dep\fP を作成したいとする。
+問題は、存在確認とファイル作成の間に、 \fIpath\fP や \fIto\fP (シンボリックリンクでもよい)
+が別の場所を指すように変更されることがあるということだ。 このような競合条件は、 対象のディレクトリに対するファイルディスクリプタをオープンし、
+それから \fBfstatat\fP(2) や \fBopenat\fP() の \fIdirfd\fP 引き数としてそのファイルディスクリプタを指定することで、
+避けることができる。
.\"
.\"
いくつかのファイルシステムでは、制限を確認するための独自のインタフェースが 提供されている。例えば、 \fBxfsctl\fP(3) の
\fBXFS_IOC_DIOINFO\fP 命令である。
.LP
-Under Linux 2.4, transfer sizes, and the alignment of the user buffer and
-the file offset must all be multiples of the logical block size of the
-filesystem. Since Linux 2.6.0, alignment to the logical block size of the
-underlying storage (typically 512 bytes) suffices. The logical block size
-can be determined using the \fBioctl\fP(2) \fBBLKSSZGET\fP operation or from the
-shell using the command:
+Linux 2.4 では、転送サイズ、 ユーザーバッファのアライメント、ファイルオフセットは、
+ファイルシステムの論理ブロックサイズの倍数でなければならない。 Linux 2.6.0 以降では、
+内部で使われるストレージの論理ブロックサイズのアライメント (通常は 512 バイト) で十分である。 論理ブロックサイズは \fBioctl\fP(2)
+\fBBLKSSZGET\fP 操作や以下のシェルコマンドから知ることができる。
blockdev \-\-getss
.LP
は発生しないので st_atime の更新は行なわれからだ。 UNIX の方式では、クライアント側の属性のキャッシングを無効にすることで、
これを得ることができる。しかしほとんどの状況ではこれは続くサーバーの 負荷を増加させ、パフォーマンスの低下をもたらす。
.SH バグ
-According to POSIX.1\-2008/SUSv4 Section XSI 2.9.7 ("Thread Interactions with
-Regular File Operations"):
+POSIX.1\-2008/SUSv4 セクション XSI 2.9.7 ("Thread Interactions with Regular File
+Operations") によると、
.RS 4
-All of the following functions shall be atomic with respect to each other in
-the effects specified in POSIX.1\-2008 when they operate on regular files or
-symbolic links: ...
+以下のすべての関数では、 通常ファイルもしくはシンボリックリンクに対する操作では POSIX.1\-2008
+で規定された効果が互いにアトミックに行われなければならない: ...
.RE
.\" http://thread.gmane.org/gmane.linux.kernel/1649458
.\" Date: Mon Mar 3 09:36:58 2014 -0800
.\"
.\" vfs: atomic f_pos accesses as per POSIX
-Among the APIs subsequently listed are \fBread\fP() and \fBreadv\fP(2). And
-among the effects that should be atomic across threads (and processes) are
-updates of the file offset. However, on Linux before version 3.14, this was
-not the case: if two processes that share an open file description (see
-\fBopen\fP(2)) perform a \fBread\fP() (or \fBreadv\fP(2)) at the same time, then
-the I/O operations were not atomic with respect updating the file offset,
-with the result that the reads in the two processes might (incorrectly)
-overlap in the blocks of data that they obtained. This problem was fixed in
-Linux 3.14.
+この後に書かれている API の中に \fBread\fP() と \fBreadv\fP(2) である。 スレッド（やプロセス)
+間でアトミックに適用することが求められる効果の一つとして、 ファイルオフセットの更新がある。 しかしながら、 バージョン 3.14 より前の Linux
+では、 この限りではない。 オープンファイル記述 (open file description) を共有する 2 つのプロセスが同時に
+\fBread\fP() (や \fBreadv\fP(2)) を実行した場合、 この I/O 操作ではファイルオフセットの更新に関してはアトミックではなく、 2
+つのプロセスの read で取得されるデータブロックが (間違って) 重なる可能性がある。 この問題は Linux 3.14 で修正された。
.SH 関連項目
\fBclose\fP(2), \fBfcntl\fP(2), \fBioctl\fP(2), \fBlseek\fP(2), \fBopen\fP(2), \fBpread\fP(2),
\fBreaddir\fP(2), \fBreadlink\fP(2), \fBreadv\fP(2), \fBselect\fP(2), \fBwrite\fP(2),
\fBrenameat\fP() の必要性についての説明については \fBopenat\fP(2) を参照。
.SS renameat2()
-\fBrenameat2\fP() has an additional \fIflags\fP argument. A \fBrenameat2\fP() call
-with a zero \fIflags\fP argument is equivalent to \fBrenameat\fP().
+\fBrenameat2\fP() には追加の \fIflags\fP 引き数がある。 \fIflags\fP 引き数が 0 の \fBrenameat2\fP()
+の呼び出しは \fBrenameat\fP() と等価である。
-The \fIflags\fP argument is a bit mask consisting of zero or more of the
-following flags:
+\fIflags\fP 引き数は、以下のフラグの 0 個以上のビットマスクである。
.TP
\fBRENAME_NOREPLACE\fP
-Don't overwrite \fInewpath\fP. of the rename. Return an error if \fInewpath\fP
-already exists.
+rename の \fInewpath\fP を上書きしない。 \fInewpath\fP がすでに存在する場合エラーを返す。
.TP
\fBRENAME_EXCHANGE\fP
-Atomically exchange \fIoldpath\fP and \fInewpath\fP. Both pathnames must exist
-but may be of different types (e.g., one could be a non\-empty directory and
-the other a symbolic link).
+\fIoldpath\fP と \fInewpath\fP をアトミックに入れ換える。 両方のパス名が存在しなければならないが、 ファイル種別は異なっていてもよい
+(例えば、一方は空でないディレクトリで、もう一方はシンボリックリンクであるなど)。
.SH 返り値
成功した場合は 0 が返される。エラーの場合は \-1 が返され、 \fIerrno\fP が適切に設定される。
.SH エラー
\fBrenameat2\fP() では以下のエラーも発生する。
.TP
\fBEEXIST\fP
-\fIflags\fP contains \fBRENAME_NOREPLACE\fP and \fInewpath\fP already exists.
+\fIflags\fP に \fBRENAME_NOREPLACE\fP が指定されているが、 \fInewpath\fP がすでに存在する。
.TP
\fBEINVAL\fP
-An invalid flag was specified in \fIflags\fP, or both \fBRENAME_NOREPLACE\fP and
-\fBRENAME_EXCHANGE\fP were specified.
+\fIflags\fP に無効なフラグが指定された。 \fBRENAME_NOREPLACE\fP と \fBRENAME_EXCHANGE\fP の両方が指定された。
.TP
\fBEINVAL\fP
-The filesystem does not support one of the flags in \fIflags\fP.
+\fIflags\fP にファイルシステムでサポートされていないフラグが指定された。
.TP
\fBENOENT\fP
-\fIflags\fP contains \fBRENAME_EXCHANGE\fP and \fInewpath\fP does not exist.
+\fIflags\fP に \fBRENAME_EXCHANGE\fP が指定されたが、 \fInewpath\fP が存在しない。
.SH バージョン
\fBrenameat\fP() はカーネル 2.6.16 で Linux に追加された。 ライブラリによるサポートはバージョン 2.4 で glibc
に追加された。
--- /dev/null
+.\" Copyright (C) 2014 Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (C) 2014 Peter Zijlstra <peterz@infradead.org>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date. The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein. The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH SCHED_SETATTR 2 2014\-10\-02 Linux "Linux Programmer's Manual"
+.SH 名前
+sched_setattr, sched_getattr \- スケジューリングポリシーと属性の設定と取得を行なう
+.SH 書式
+.nf
+\fB#include <sched.h>\fP
+
+\fBint sched_setattr(pid_t \fP\fIpid\fP\fB, const struct sched_attr *\fP\fIattr\fP\fB,\fP
+\fB unsigned int \fP\fIflags\fP\fB);\fP
+
+\fBint sched_getattr(pid_t \fP\fIpid\fP\fB, const struct sched_attr *\fP\fIattr\fP\fB,\fP
+\fB unsigned int \fP\fIsize\fP\fB, unsigned int \fP\fIflags\fP\fB);\fP
+.fi
+.\" FIXME . Add feature test macro requirements
+.SH 説明
+.SS sched_setattr()
+\fBsched_setattr\fP() システムコールは、 \fIpid\fP で指定された ID
+を持つスレッドのスケジューリングポリシーと関連する属性を設定する。 \fIpid\fP が 0
+の場合、呼び出したスレッド自身のスケジューリングポリシーと属性が設定される。
+
+現在のところ、 Linux では、 以下の「通常」の (つまり、リアルタイムではない) スケジューリングポリシーが、 \fIpolicy\fP
+に指定できる値としてサポートされている。
+.TP 14
+\fBSCHED_OTHER\fP
+.\" In the 2.6 kernel sources, SCHED_OTHER is actually called
+.\" SCHED_NORMAL.
+標準の、ラウンドロビンによる時分割型のスケジューリングポリシー。
+.TP
+\fBSCHED_BATCH\fP
+「バッチ」形式でのプロセスの実行用。
+.TP
+\fBSCHED_IDLE\fP
+「非常に」低い優先度で動作するバックグラウンドジョブ用。
+.PP
+どの実行可能スレッドを選択するかについて、より正確な制御を必要とする 時間の制約が厳しい特別なアプリケーション用として、
+いろいろな「リアルタイム」ポリシーもサポートされている。 プロセスがこれらのポリシーをいつ使用できるかを決めるルールについては、\fBsched\fP(7)
+を参照。 \fIpolicy\fP には以下のリアルタイムポリシーを指定できる。
+.TP 14
+\fBSCHED_FIFO\fP
+ファーストイン、ファーストアウト型のポリシー。
+.TP
+\fBSCHED_RR\fP
+ラウンドロビン型のポリシー。
+.PP
+Linux では以下のポリシーも提供されている。
+.TP 14
+\fBSCHED_DEADLINE\fP
+デッドライン (応答期限) ベースのスケジューリングポリシー。詳細は \fBsched\fP(7) を参照。
+.PP
+\fIattr\fP 引き数は、 指定したスレッドの新しいスケジューリングポリシーと属性を定義した構造体へのポインターである。 この構造体は以下の形式である。
+
+.in +4n
+.nf
+struct sched_attr {
+ u32 size; /* この構造体のサイズ */
+ u32 sched_policy; /* ポリシー (SCHED_*) */
+ u64 sched_flags; /* フラグ */
+ s32 sched_nice; /* nice 値 (SCHED_OTHER,
+ SCHED_BATCH) */
+ u32 sched_priority; /* 静的優先度 (SCHED_FIFO,
+ SCHED_RR) */
+ /* 残りのフィールドは SCHED_DEADLINE 用である */
+ u64 sched_runtime;
+ u64 sched_deadline;
+ u64 sched_period;
+};
+.fi
+.in
+
+この構造体のフィールドは以下の通りである。
+.TP
+\fBsize\fP
+このフィールドには、 構造体のバイト単位のサイズを設定する。 \fIsizeof(struct sched_attr)\fP を指定すればよい。
+指定された構造体がカーネル構造体よりも小さい場合、 追加となるフィールドは 0 とみなされる。 指定された構造体がカーネル構造体よりも大きい場合、
+カーネルは追加のフィールドが 0 であるかを検査する。 0 でない場合は \fBsched_setattr\fP() はエラー \fBE2BIG\fP
+で失敗するので、 \fIsize\fP をカーネル構造体のサイズに更新する必要がある。
+.IP
+ユーザー空間の \fIsched_attr\fP 構造体のサイズがカーネル構造体のサイズと一致しなかった場合の上記の動作は、
+このインタフェースを将来拡張できるようにするためである。 サイズが大きい構造体を渡す行儀の良くないアプリケーションも、 将来カーネルの
+\fIsched_attr\fP 構造体のサイズが大きくなったとしてもおかしくならない。 この仕組みにより、 将来的には、 大きなユーザー空間
+\fIsched_attr\fP 構造体があることを知っているアプリケーションで、
+大きいサイズの構造体に対応していない古いカーネル上で動作しているかを判定することができる。
+.TP
+\fIsched_policy\fP
+このフィールドはスケジューリングポリシーを指定する。 上記のリストにある \fBSCHED_*\fP 値のいずれかを指定する。
+.TP
+\fIsched_flags\fP
+このフィールドはスケジューリング動作の制御を行う。 現在のところ、サポートされているフラグは \fBSCHED_FLAG_RESET_ON_FORK\fP
+の一つだけである。 このフラグが指定されると、 \fBfork\fP(2) で作成された子プロセスは特権が必要なスケジューリングポリシーを継承しない。 詳細は
+\fBsched\fP(7) を参照。
+.TP
+\fIsched_nice\fP
+このフィールドは、 \fIsched_policy\fP に \fBSCHED_OTHER\fP か \fBSCHED_BATCH\fP が指定された場合に設定される
+nice 値を指定する。 nice 値は \-20 (高優先度) から +19 (低優先度) の範囲の数値である。 \fBsetpriority\fP(2)
+を参照。
+.TP
+\fIsched_priority\fP
+このフィールドは、 \fIsched_policy\fP に \fBSCHED_FIFO\fP か \fBSCHED_RR\fP
+が指定された場合に設定される静的優先度を指定する。 これらのポリシーで指定できる優先度の範囲は、
+\fBsched_get_priority_min\fP(2) と \fBsched_get_priority_max\fP(2) を使って判定できる。
+他のポリシーでは、 このフィールドには 0 を指定しなければならない。
+.TP
+\fIsched_runtime\fP
+このフィールドは、 デッドラインスケジューリングの "Runtime" パラメーターを指定する。 この値はナノ秒単位で表現される。 このフィールドと次の
+2 つのフィールドは \fBSCHED_DEADLINE\fP スケジューリングにおいてのみ使用される。 詳細は \fBsched\fP(7) を参照。
+.TP
+\fIsched_deadline\fP
+このフィールドは、 デッドラインスケジューリングの "Deadline" パラメーターを指定する。 この値はナノ秒単位で表現される。
+.TP
+\fIsched_period\fP
+このフィールドは、 デッドラインスケジューリングの "Period" パラメーターを指定する。 この値はナノ秒単位で表現される。
+.PP
+.\"
+.\"
+\fIflags\fP 引き数は、このインタフェースの将来の拡張のために用意されている。 現在の実装では 0 を指定しなければならない。
+.SS sched_getattr()
+\fBsched_getattr\fP() システムコールは、 \fIpid\fP で指定された ID
+を持つスレッドのスケジューリングポリシーと関連する属性を取得する。 \fIpid\fP が 0
+の場合、呼び出したスレッド自身のスケジューリングポリシーと関連する属性を取得する。
+
+\fIsize\fP 引き数には、 ユーザー空間での \fIsched_attr\fP 構造体の大きさを設定する。 この値は、 少なくとも初期バージョンの
+\fIsched_attr\fP 構造体のサイズでなければならない。 そうでなかった場合、 エラー \fBEINVAL\fP で呼び出しが失敗する。
+
+取得したスケジューリング属性は、 \fIattr\fP が指す \fIsched_attr\fP 構造体の各フィールドに格納される。 カーネルは
+\fIattr.size\fP に \fIsched_attr\fP 構造体のサイズを設定する。
+
+呼び出し側が提供した \fIattr\fP バッファがカーネルの \fIsched_attr\fP 構造体よりも大きい場合、
+ユーザー空間構造体の残りのバイトは変更されない。 呼び出し側が提供した構造体がカーネルの \fIsched_attr\fP 構造体よりも小さく、
+カーネルが値を返すのにもっと大きな空間が必要な場合、 \fBsched_getattr\fP() はエラー \fBE2BIG\fP で失敗する。
+\fBsched_setattr\fP() と同様、 この動作はこのインタフェースの将来の拡張性を考慮してのものである。
+
+\fIflags\fP 引き数は、このインタフェースの将来の拡張のために用意されている。 現在の実装では 0 を指定しなければならない。
+.SH 返り値
+成功した場合は \fBsched_setattr\fP() と \fBsched_getattr\fP() は 0 を返す。 エラーの場合は \-1 が返され、
+エラーの原因を示す値が \fIerrno\fP に設定される。
+.SH エラー
+\fBsched_getattr\fP() と \fBsched_setattr\fP() の両方が以下の理由で失敗する。
+.TP
+\fBEINVAL\fP
+\fIattr\fP が NULL である。 \fIpid\fP が負である。 \fIflags\fP が 0 以外である。
+.TP
+\fBESRCH\fP
+ID が \fIpid\fP のスレッドが見つからなかった。
+.PP
+さらに、 \fBsched_getattr\fP() は以下の理由でも失敗する。
+.TP
+\fBE2BIG\fP
+\fIsize\fP と \fIattr\fP で指定されたバッファーが小さすぎる。
+.TP
+\fBEINVAL\fP
+\fIsize\fP が無効である。つまり、 最初のバージョンの \fIsched_attr\fP 構造体 (48 バイト) よりも小さいか、
+システムのページサイズよりも大きい。
+.PP
+さらに、 \fBsched_setattr\fP() は以下の理由でも失敗する。
+.TP
+\fBE2BIG\fP
+\fIsize\fP と \fIattr\fP で指定されたバッファがカーネル構造体よりも大きく、 一つ以上の超過バイトが 0 でなかった。
+.TP
+\fBEBUSY\fP
+\fBSCHED_DEADLINE\fP の流入制御の失敗については \fBsched\fP(7) を参照。
+.TP
+\fBEINVAL\fP
+\fIattr.sched_policy\fP が認識できるポリシーではない。 \fIattr.sched_flags\fP に
+\fBSCHED_FLAG_RESET_ON_FORK\fP 以外のフラグが含まれている。 \fIattr.sched_priority\fP が無効である。
+\fIattr.sched_policy\fP が \fBSCHED_DEADLINE\fP で、 \fIattr\fP
+に指定されたデッドラインスケジューリングパラメーターが無効である。
+.TP
+\fBEPERM\fP
+呼び出した元が適切な特権を持っていない。
+.TP
+\fBEPERM\fP
+呼び出し元の CPU affinity マスクにシステムの全ての CPU のうち含まれていないものがある
+(\fBsched_setaffinity\fP(2) を参照)。
+.SH バージョン
+.\" FIXME . Add glibc version
+これらのシステムコールは Linux 3.14 で初めて登場した。
+.SH 準拠
+これらのシステムコールは非標準の Linux による拡張である。
+.SH 注意
+\fBsched_setattr\fP() は、\fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2),
+\fBnice\fP(2) の機能および \fBsetpriority\fP の一部機能を持つ (ただし、\fBsetpriority\fP(2)
+の、指定されたユーザーに所属するすべてのプロセスまたは指定されたグループのすべてのプロセスの優先度を設定する機能は除く)。 同様に、
+\fBsched_getattr()\fP は \fBsched_getscheduler\fP(2), \fBsched_getparam\fP(2) の機能および
+\fBgetpriority\fP(2) の一部機能を持つ。
+.SH バグ
+.\" FIXME . patch sent to Peter Zijlstra
+.\" In Linux versions up to up 3.15,
+.\" FIXME . patch from Peter Zijlstra pending
+.\" .BR sched_setattr ()
+.\" allowed a negative
+.\" .I attr.sched_policy
+.\" value.
+バージョン 3.15 までの Linux では、 \fBsched_settattr\fP() は、 エラーの節に書かれている \fBE2BIG\fP
+の場合にエラー\fBEFAULT\fP で失敗していた。
+.SH 関連項目
+.ad l
+.nh
+\fBchrt\fP(1), \fBnice\fP(2), \fBsched_get_priority_max\fP(2),
+\fBsched_get_priority_min\fP(2), \fBsched_getaffinity\fP(2),
+\fBsched_getscheduler\fP(2), \fBsched_getparam\fP(2), \fBsched_rr_get_interval\fP(2),
+\fBsched_setaffinity\fP(2), \fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2),
+\fBsched_yield\fP(2), \fBsetpriority\fP(2), \fBpthread_getschedparam\fP(3),
+\fBpthread_setschedparam\fP(3), \fBpthread_setschedprio\fP(3), \fBcapabilities\fP(7),
+\fBcpuset\fP(7), \fBsched\fP(7)
+.ad
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
を持つスレッドのスケジューリングポリシーとスケジューリングパラメーターの両方を設定する。 \fIpid\fP が 0
の場合、呼び出したスレッド自身のスケジューリングポリシーとスケジューリングパラメーターが設定される。
-The scheduling parameters are specified in the \fIparam\fP argument, which is a
-pointer to a structure of the following form:
+スケジューリングパラメーターは \fIparam\fP 引き数で、以下の形式の構造体へのポインターを指定する。
.nf
.in +4n
.in
.fi
-In the current implementation, the structure contains only one field,
-\fIsched_priority\fP. The interpretation of \fIparam\fP depends on the selected
-policy.
+現在の実装では、この構造体のフィールドは \fIsched_priority\fP だけである。 \fIparam\fP
+がどのように解釈されるかは選択されたポリシーによって変わる。
-Currently, Linux supports the following "normal" (i.e., non\-real\-time)
-scheduling policies as values that may be specified in \fIpolicy\fP:
+現在のところ、 Linux では、 以下の「通常」の (つまり、リアルタイムではない) スケジューリングポリシーが、 \fIpolicy\fP
+に指定できる値としてサポートされている。
.TP 14
\fBSCHED_OTHER\fP
.\" In the 2.6 kernel sources, SCHED_OTHER is actually called
\fBSCHED_IDLE\fP
「非常に」低い優先度で動作するバックグラウンドジョブ用。
.PP
-For each of the above policies, \fIparam\->sched_priority\fP must be 0.
+上記のどのポリシーの場合でも、 \fIparam\->sched_priority\fP は 0 でなければならない。
どの実行可能スレッドを選択するかについて、より正確な制御を必要とする 時間の制約が厳しい特別なアプリケーション用として、
いろいろな「リアルタイム」ポリシーもサポートされている。 プロセスがこれらのポリシーをいつ使用できるかを決めるルールについては、\fBsched\fP(7)
\fBSCHED_RR\fP
ラウンドロビン型のポリシー。
.PP
-For each of the above policies, \fIparam\->sched_priority\fP specifies a
-scheduling priority for the thread. This is a number in the range returned
-by calling \fBsched_get_priority_min\fP(2) and \fBsched_get_priority_max\fP(2)
-with the specified \fIpolicy\fP. On Linux, these system calls return,
-respectively, 1 and 99.
+上記のどのポリシーの場合でも、 \fIparam\->sched_priority\fP はそのスレッドのスケジューリングポリシーを指定する。
+指定された \fIpolicy\fP で \fIsched_get_priority_min\fP(2) と
+\fIsched_get_priority_max\fP(2) を呼び出した返り値の範囲の数字を指定する。 Linux では、これらのシステムコールはそれぞれ
+1 と 99 を返す。
Linux 2.6.32 以降では、 \fBsched_setscheduler\fP() を呼び出す際に \fIpolicy\fP に
\fBSCHED_RESET_ON_FORK\fP フラグを OR で指定できる。このフラグが指定されると、 \fBfork\fP(2)
POSIX.1\-2001 (但し、下記のバグの節も参照)。 \fBSCHED_BATCH\fP と \fBSCHED_IDLE\fP ポリシーは Linux
固有である。
.SH 注意
-Further details of the semantics of all of the above "normal" and
-"real\-time" scheduling policies can be found in \fBsched\fP(7).
+上記の「通常」および「リアルタイム」スケジューリングポリシーの動作の詳細な説明は \fBsched\fP(7) にある。
POSIX システムでは \fI<unistd.h>\fP に \fB_POSIX_PRIORITY_SCHEDULING\fP
が定義されている場合にのみ \fBsched_setscheduler\fP() と \fBsched_getscheduler\fP() が使用できる。
\fBwrite\fP() が 1 バイトも書き込まないうちにシグナルハンドラにより割り込まれた場合、 \fBwrite\fP() はエラー \fBEINTR\fP
で失敗する。 1バイトでも書き込んだ後で割り込まれた場合には、 \fBwrite\fP() は成功し、書き込んだバイト数を返す。
.SH バグ
-According to POSIX.1\-2008/SUSv4 Section XSI 2.9.7 ("Thread Interactions with
-Regular File Operations"):
+POSIX.1\-2008/SUSv4 セクション XSI 2.9.7 ("Thread Interactions with Regular File
+Operations") によると、
.RS 4
-All of the following functions shall be atomic with respect to each other in
-the effects specified in POSIX.1\-2008 when they operate on regular files or
-symbolic links: ...
+以下のすべての関数では、 通常ファイルもしくはシンボリックリンクに対する操作では POSIX.1\-2008
+で規定された効果が互いにアトミックに行われなければならない: ...
.RE
.\" http://thread.gmane.org/gmane.linux.kernel/1649458
.\" Date: Mon Mar 3 09:36:58 2014 -0800
.\"
.\" vfs: atomic f_pos accesses as per POSIX
-Among the APIs subsequently listed are \fBwrite\fP() and \fBwritev\fP(2). And
-among the effects that should be atomic across threads (and processes) are
-updates of the file offset. However, on Linux before version 3.14, this was
-not the case: if two processes that share an open file description (see
-\fBopen\fP(2)) perform a \fBwrite\fP() (or \fBwritev\fP(2)) at the same time, then
-the I/O operations were not atomic with respect updating the file offset,
-with the result that the blocks of data output by the two processes might
-(incorrectly) overlap. This problem was fixed in Linux 3.14.
+この後に書かれている API の中に \fBwrite\fP() と \fBwritev\fP(2) である。 スレッド（やプロセス)
+間でアトミックに適用することが求められる効果の一つとして、 ファイルオフセットの更新がある。 しかしながら、 バージョン 3.14 より前の Linux
+では、 この限りではない。 オープンファイル記述 (open file description) を共有する 2 つのプロセスが同時に
+\fBwrite\fP() (や \fBwritev\fP(2)) を実行した場合、 この I/O 操作ではファイルオフセットの更新に関してはアトミックではなく、
+2 つのプロセスから出力されるデータブロックが (間違って) 重なる可能性がある。 この問題は Linux 3.14 で修正された。
.SH 関連項目
\fBclose\fP(2), \fBfcntl\fP(2), \fBfsync\fP(2), \fBioctl\fP(2), \fBlseek\fP(2), \fBopen\fP(2),
\fBpwrite\fP(2), \fBread\fP(2), \fBselect\fP(2), \fBwritev\fP(2), \fBfwrite\fP(3)
であることを示す。 (C99 では %LF を使うことを認めているが、SUSv2 では認められていない。) これは \fBll\fP の同義語である。
.TP
\fBj\fP
-A following integer conversion corresponds to an \fIintmax_t\fP or \fIuintmax_t\fP
-argument, or a following \fBn\fP conversion corresponds to a pointer to an
-\fIintmax_t\fP argument.
+整数変換に対応する引き数が \fIintmax_t\fP か \fIuintmax_t\fP で、 \fBn\fP 変換に対応する引き数が \fIintmax_t\fP
+へのポインタであることを示す。
.TP
\fBz\fP
.\" (Linux libc5 has
.\" .B Z
.\" with this meaning.
.\" Don't use it.)
-A following integer conversion corresponds to a \fIsize_t\fP or \fIssize_t\fP
-argument, or a following \fBn\fP conversion corresponds to a pointer to a
-\fIsize_t\fP argument.
+整数変換に対応する引き数が \fIsize_t\fP か \fIssize_t\fP で、 \fBn\fP 変換に対応する引き数が \fIsize_t\fP
+へのポインタであることを示す。
.TP
\fBt\fP
-A following integer conversion corresponds to a \fIptrdiff_t\fP argument, or a
-following \fBn\fP conversion corresponds to a pointer to a \fIptrdiff_t\fP
-argument.
+整数変換に対応する引き数が \fIptrdiff_t\fP で、 \fBn\fP 変換に対応する引き数が \fIptrdiff_t\fP へのポインタであることを示す。
.PP
SUSv3 では上記のすべてが規定されている。 SUSv2 で規定されていたのは、 長さ修飾子 \fBh\fP (\fBhd\fP, \fBhi\fP, \fBho\fP,
\fBhx\fP, \fBhX\fP, \fBhn\fP), \fBl\fP (\fBld\fP, \fBli\fP, \fBlo\fP, \fBlx\fP, \fBlX\fP, \fBln\fP, \fBlc\fP,
精度が指定されていない場合には 6 として扱われる。 精度として明示的に 0 が指定されたときには、小数点以下は表示されない。
小数点を表示する際には、小数点の前に少なくとも一桁は数字が表示される。
-(SUSv2 does not know about \fBF\fP and says that character string
-representations for infinity and NaN may be made available. SUSv3 adds a
-specification for \fBF\fP. The C99 standard specifies "[\-]inf" or
-"[\-]infinity" for infinity, and a string starting with "nan" for NaN, in the
-case of \fBf\fP conversion, and "[\-]INF" or "[\-]INFINITY" or "NAN*" in the case
-of \fBF\fP conversion.)
+(SUSv2 では、\fBF\fP は規定されておらず、無限や NaN に関する文字列表現を行ってもよいことになっている。 SUSv3 では \fBF\fP
+の規定が追加された。 C99 標準では、\fBf\fP 変換では、無限は "[\-]inf" か "[\-]infinity" と表示し、 NaN
+は文字列の先頭に `nan' をつけて表示するように規定されている。 \fBF\fP 変換の場合は "[\-]INF", "[\-]INFINITY",
+"NAN*" と表示される。)
.TP
\fBg\fP, \fBG\fP
\fIdouble\fP 引き数を \fBf\fP か \fBe\fP (\fBG\fP 変換の場合は \fBF\fP か \fBE\fP) の形式に変換する。
小数点以下に数字が少なくとも一つある場合にだけである。
.TP
\fBa\fP, \fBA\fP
-(C99; not in SUSv2, but added in SUSv3) For \fBa\fP conversion, the \fIdouble\fP
-argument is converted to hexadecimal notation (using the letters abcdef) in
-the style [\-]\fB0x\fPh\fB\&.\fPhhhh\fBp\fP\(+-; for \fBA\fP conversion the prefix \fB0X\fP,
-the letters ABCDEF, and the exponent separator \fBP\fP is used. There is one
-hexadecimal digit before the decimal point, and the number of digits after
-it is equal to the precision. The default precision suffices for an exact
-representation of the value if an exact representation in base 2 exists and
-otherwise is sufficiently large to distinguish values of type \fIdouble\fP.
-The digit before the decimal point is unspecified for nonnormalized numbers,
-and nonzero but otherwise unspecified for normalized numbers.
+(C99 にはあるが SUSv2 にはないが SUSv3 で追加された)
+\fBa\fP 変換では、 \fIdouble\fP 引き数を
+(abcdef の文字を使って) [\-]\fB0x\fPh\fB\&.\fPhhhh\fBp\fP\(+- 形式の
+16 進表記に変換する。
+\fBA\fP 変換では、前置文字列 \fB0X\fP, 文字 ABCDEF, 指数文字 \fBP\fP を用いる。
+小数点の前には 1 桁の 16 進数が置かれ、小数点の後ろの桁数は 精度で指定
+された値となる。デフォルトの精度は、その値が 2 進数で正確に表現できる
+場合には、その値を正確に表現できる桁数となる。それ以外の場合は、
+\fIdouble\fP 型の値を区別するのに十分な大きさとなる。 小数点の前の数字は、
+正規化されていない数の場合はいくつになるか分からない。 正規化された数の
+場合は、 0 以外の値になるが、いくつになるかは分からない。
.TP
\fBc\fP
\fBl\fP 修飾子がなければ、 \fIint\fP 引き数を \fIunsigned char\fP に変換して、その結果に対応する文字を出力する。 \fBl\fP
精度の値を超える場合だけは、配列はヌルワイド文字で終端されていなくてもよい。 それ以外の場合は、必ず配列はヌルワイド文字で終端されていなければならない。
.TP
\fBC\fP
-(Not in C99 or C11, but in SUSv2, SUSv3, and SUSv4.) Synonym for \fBlc\fP.
-Don't use.
+(C99, C11 にはないが SUSv2, SUSv3, SUSv4 にはある) \fBlc\fP と同じ。使ってはならない。
.TP
\fBS\fP
-(Not in C99 or C11, but in SUSv2, SUSv3, and SUSv4.) Synonym for \fBls\fP.
-Don't use.
+(C99, C11 にはないが SUSv2, SUSv3, SUSv4 にはある) \fBls\fP と同じ。使ってはならない。
.TP
\fBp\fP
\fIvoid\ *\fP ポインタ引き数を (\fB%#x\fP や \fB%#lx\fP のような) 16 進数で出力する。
.TP
\fBn\fP
-The number of characters written so far is stored into the integer pointed
-to by the corresponding argument. That argument shall be an \fIint\ * ,\fP or
-variant whose size matches the (optionally) supplied integer length
-modifier. No argument is converted. The behavior is undefined if the
-conversion specification includes any flags, a field width, or a precision.
+これまでに書き込まれた文字数が対応する引き数が指す整数に格納される。 この引き数は \fIint\ *\fP
+系でなければならず、そのサイズは指定された整数の長さ修飾子 (省略可能) と一致していなければならない。 引き数の変換は行われない。
+変換指定にフラグ、フィールド幅、精度に含まれていた場合の動作は不定である。
.TP
\fBm\fP
(glibc での拡張) \fIstrerror(errno)\fP の出力を表示する。引き数は必要ない。
.\" .IR strerror(errno) .
.\" .PP
.\" glibc 2.0 adds conversion characters \fBC\fP and \fBS\fP.
-Concerning the return value of \fBsnprintf\fP(), SUSv2 and C99 contradict each
-other: when \fBsnprintf\fP() is called with \fIsize\fP=0 then SUSv2 stipulates an
-unspecified return value less than 1, while C99 allows \fIstr\fP to be NULL in
-this case, and gives the return value (as always) as the number of
-characters that would have been written in case the output string has been
-large enough. SUSv3 and later align their specification of \fBsnprintf\fP()
-with C99.
+\fBsnprintf\fP() の返り値を見ると、 SUSv2 と C99 標準は互いに矛盾している。 SUSv2 では、 \fBsnprintf\fP()
+が \fIsize\fP=0 で呼び出された場合、 1 未満の値を何か返り値とするように規定している。 一方 C99 では、このような場合 \fIstr\fP を
+NULL とし、返り値として (通常通り) 出力バッファが十分な大きさが あった場合に出力されるであろう文字数を返す。 SUSv3 やそれ以降では
+C99 の \fBsnprintf\fP() の規定にあわせたものとなっている。
.PP
glibc 2.1 では、長さ修飾子 \fBhh\fP, \fBj\fP, \fBt\fP, \fBz\fP と変換文字 \fBa\fP, \fBA\fP が追加された。
.PP
--- /dev/null
+.\" Copyright (c) 2013 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (c) 2012 by Eric W. Biederman <ebiederm@xmission.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date. The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein. The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH PID_NAMESPACES 7 2014\-09\-21 Linux "Linux Programmer's Manual"
+.SH 名前
+pid_namespaces \- Linux PID 名前空間の概要
+.SH 説明
+名前空間の概要については \fBnamespaces\fP(7) を参照。
+
+PID 名前空間はプロセス ID 番号空間を分離する。 これは、異なる PID 名前空間のプロセスは同じ PID を持つことができることを意味する。
+PID 名前空間を使うことで、コンテナー内のプロセス群を中断、再開したり、 コンテナー内のプロセスの PID
+を保持したままコンテナーを新しいホストに移行したりするといった機能をコンテナーが提供することが可能になる。
+
+新しい PID 名前空間の PID は、 独立したシステムであるかのように、 1 から始まる。 \fBfork\fP(2), \fBvfork\fP(2),
+\fBclone\fP(2) を呼び出すと、 その名前空間内で一意な PID でプロセスが生成される。
+
+.\"
+.\" ============================================================
+.\"
+PID 名前空間を使用するには、設定 \fBCONFIG_PID_NS\fP が有効になったカーネルが必要である。
+.SS "名前空間の init プロセス"
+新しい名前空間で作成される最初のプロセス (すなわち、\fBCLONE_NEWPID\fP フラグで \fBclone\fP(2) を使って作成されたプロセスや、
+\fBCLONE_NEWPID\fP フラグで \fBunshare\fP(2) を呼び出した後のプロセスによって作成された最初のプロセス) は PID 1
+を持ち、 そのプロセスはその名前空間の "init" プロセスとなる (\fBinit\fP(1) 参照)。 名前空間内でみなしごになった
+(親プロセスがいなくなった) 子プロセスは、 \fBinit\fP(1) ではなくこのプロセスが親プロセスになる (ただし、 同じ PID
+名前空間内のその子プロセスの先祖が、 \fBprctl\fP(2) の \fBPR_SET_CHILD_SUBREAPER\fP コマンドを使って、
+自分自身をみなしごとなった子孫のプロセスの引き取り手になっている場合はこの限りではなく)。
+
+PID 名前空間の "init" プロセスが終了すると、 カーネルはその名前空間の全プロセスを \fBSIGKILL\fP シグナルで終了する。 この動作は、
+PID 名前空間の正しい操作のためには "init" プロセスは不可欠であるという事実を反映したものである。 この場合、 その PID
+名前空間へのそれ以降の \fBfork\fP(2) はエラー \fBENOMEM\fP で失敗する。 "init" プロセスが終了している PID
+名前空間に新しいプロセスを作成することはできない。 このような状況は、 例えば、 名前空間にいたプロセスに対応する
+\fI/proc/[pid]/ns/pid\fP ファイルに対してオープンしたファイルディスクリプタを使って、 "init"
+プロセスが終了した後にその名前空間に \fBsetns\fP(2) を行った場合に起こり得る。 \fBunshare\fP(2)
+を呼び出した後にも、この状況は起こり得る。 それ以降に \fBfork\fP(2) で作成された最初の子プロセスが終了すると、 それ以降の
+\fBfork\fP(2) の呼び出しは \fBNOMEM\fP で失敗する。
+
+PID 名前空間の他のメンバーは、 "init" プロセスがシグナルハンドラーを設定したシグナルだけを、 "init" プロセスに送信することができる。
+この制限は特権プロセスに対しても適用される。 この制限により、 PID 名前空間の他のメンバーがうっかり "init"
+プロセスを殺してしまうのを防ぐことができる。
+
+同様に、 先祖の名前空間のプロセスは、 "init" プロセスがそのシグナルに対するハンドラーを設定している場合にのみ、 \fBkill\fP(2)
+で説明されている通常のアクセス許可のチェックを経た上で、 子供の PID 名前空間の "init" プロセスにシグナルを送信できる。
+(ハンドラー内では、 \fIsigaction\fP(2) に説明がある \fIsiginfo_t\fP の \fIsi_pid\fP フィールドは 0 になる。)
+\fBSIGKILL\fP と \fBSIGSTOP\fP は例外として扱われ、 これらのシグナルが先祖の PID
+名前空間から送信された場合には強制的に配送される。 これらのシグナルはどちらも "init" プロセルが捕捉することはできない。
+そのため、これらのシグナルに関連付けられた通常のアクション (それぞれ、プロセスの終了とプロセスの強制停止) が実行される。
+
+.\"
+.\" ============================================================
+.\"
+Linux 3.4 以降では、 \fBreboot\fP(2) システムコールを呼び出すと、 シグナルがその名前空間の "init" プロセスに送信される。
+詳細は \fBreboot\fP(2) を参照。
+.SS "ネストされた PID 名前空間"
+PID 名前空間は入れ子にすることができる。 最初の ("root") PID 名前空間以外の各 PID 名前空間は親を持つ。 PID 名前空間の親は
+\fBclone\fP(2) や \fBunshare\fP(2) を使ってその名前空間を作成したプロセスの PID 名前空間である。 したがって、 PID
+名前空間は木構造を構成し、 すべての名前空間は親を辿って行くと、最終的には root 名前空間に辿り着く。
+
+プロセスは、所属する PID 名前空間の他のプロセスから見える。また、 root PID 名前空間に向かう直径の先祖の各 PID
+名前空間のプロセスからも見える。 この場合、「見える」とは、 あるプロセスが、 他のプロセスがプロセス ID
+を指定するシステムコールを使う際に操作の対象にできることを意味する。 逆に、子供 PID 名前空間のプロセスから親や先祖の名前空間のプロセスは見えない。
+あるプロセスは自分自身の PID 名前空間とその子孫の名前空間のプロセスだけが見える (例えば、\fBkill\fP(2) でシグナルを送信したり、
+\fBsetpriority\fP(2) で nice 値を設定したり、など)。
+
+プロセスは、そのプロセスが見える PID 名前空間の階層の各層においてプロセス ID を一つ持ち、 直接の先祖の名前空間を辿ることで通って root
+PID 名前空間に至ることができる。 プロセス ID に対して操作を行うシステムコールは、常に、呼び出し元プロセスの PID 名前空間で見えるプロセス
+ID を使って操作を行う。 \fBgetpid\fP(2) の呼び出しでは、 常に、 プロセスが作成された名前空間に関連付けられた PID を返す。
+
+.\"
+.\" ============================================================
+.\"
+PID 名前空間内のプロセスは名前空間の外部に親プロセスを持つことができる。 例えば、その名前空間の初期プロセス (すなわち PID 1 を持つ
+\fBinit\fP(1) プロセス) の親プロセスは必然的に別の名前空間に属すことになる。 同様に、 あるプロセスが \fBsetns\fP(2)
+を使って子プロセスを PID 名前空間に参加させた場合、 子プロセスは \fBsetns\fP(2) の呼び出し元とは異なる PID 名前空間に属す。
+子プロセスで \fBgetppid\fP(2) を呼び出すと 0 が返される。
+.SS "setns(2) と unshare(2) の動作"
+PID 名前空間のファイルディスクリプタを指定して \fBsetns\fP(2) を呼び出したり、 \fBCLONE_NEWPID\fP フラグ付きで
+\fBunshare\fP(2) を呼び出したりすると、 その結果作成された子プロセスは呼び出し元とは異なる PID 名前空間に置かれる。
+しかし、これらの呼び出しでは呼び出し元プロセスの PID 名前空間は変更されない。 なぜなら、PID 名前空間を変更してしまうと、 呼び出し元が認識する
+(\fBgetpid\fP() が返す) 自分の PID が変わってしまい、 多くのアプリケーションやライブラリが正しく動作しなくなるからである。
+
+別の言い方をすると、 あるプロセスがどの PID 名前空間に所属するかは、 そのプロセスが作成されたときに決定され、 それ以降は変更されることはない。
+いろいろあるが、プロセス間の親子関係には、PID 名前空間の親子関係がそのまま反映されるということだ。
+プロセスの親プロセスは、同じ名前空間にいるか、もしくは直接の親 PID 名前空間にいるかのいずれかである。
+.SS "CLONE_NEWPID の他の CLONE_* フラグとの互換性"
+\fBCLONE_NEWPID\fP はいくつかの他の \fBCLONE_*\fP フラグと組み合わせることができない。
+.IP * 3
+\fBCLONE_THREAD\fP は、 プロセス内のスレッド間で互いにシグナルを送信できるようにするため、 同じ PID 名前空間に属している必要がある。
+同様に、 プロセス内の全スレッドが \fBproc\fP(5) ファイルシステムで見える必要がある。
+.IP *
+\fBCLONE_SIGHAND\fP は、同じ PID 名前空間である必要がある。 さもなければ、
+シグナルが送信された際に、シグナルを送信したプロセスのプロセス ID を意味のある形でエンコードすることができない (\fBsigaction\fP(2) の
+\fIsiginfo_t\fP 型の説明を参照)。 複数の PID 名前空間に属するプロセス間で一つのシグナルキューを共有すると、うまく動かなくなる。
+.IP *
+\fBCLONE_VM\fP は、全スレッドが同じ PID 名前空間に属している必要がある。 なぜなら、 コアダンプの観点から見ると、 2
+つのプロセスが同じアドレス空間を共有していれば、 これらはスレッドであり、コアダンプが一緒に行われるからである。 コアダンプが書き込まれる際に、
+各スレッドの PID がコアダンプに書き込まれる。 もしプロセス ID のいくつかが親 PID 名前空間に属していたとすると、 プロセス ID
+の書き込みは意味を持たなくなってしまう。
+.PP
+まとめると、 \fBCLONE_THREAD\fP, \fBCLONE_SIGHAND\fP, \fBCLONE_VM\fP では技術的な要件として PID
+名前空間が共有されている点がある。 (さらに \fBclone\fP(2) では \fBCLONE_THREAD\fP か \fBCLONE_SIGHAND\fP
+が指定された際には \fBCLONE_VM\fP が指定されている必要がある点にも注意。) したがって、以下のような順序で呼び出しを行うと (エラー
+\fBEINVAL\fP で) 失敗する。
+
+.nf
+ unshare(CLONE_NEWPID);
+ clone(..., CLONE_VM, ...); /* Fails */
+
+ setns(fd, CLONE_NEWPID);
+ clone(..., CLONE_VM, ...); /* Fails */
+
+ clone(..., CLONE_VM, ...);
+ setns(fd, CLONE_NEWPID); /* Fails */
+
+ clone(..., CLONE_VM, ...);
+ unshare(CLONE_NEWPID); /* Fails */
+.fi
+.\"
+.\" ============================================================
+.\"
+.SS "/proc と PID 名前空間"
+\fI/proc\fP ファイルシステムは、\fI/proc\fP のマウントを行ったプロセスの PID 名前空間で見えるプロセスだけを表示する。 たとえ、 その
+\fI/proc\fP ファイルシステムが他の名前空間のプロセスから参照されたとしても、そうである。
+
+新しい PID 名前空間を作成した後、 子プロセスが、自身の root ディレクトリを変更し、新しい procfs インスタンスを \fI/proc\fP
+にマウントするのは \fBps\fP(1) などのツールが正しく動作するためにも有用である。 \fBclone\fP(2) の \fIflags\fP 引き数に
+\fBCLONE_NEWNS\fP も指定されて新しいマウント名前空間が同時に作成された場合は、 root ディレクトリを変更する必要はない。 新しい
+procfs インスタンスを \fI/proc\fP にそのままマウントすることができる。
+
+シェルから、コマンドで \fI/proc\fP のマウントを行うには次のようにする。
+
+ $ mount \-t proc proc /proc
+
+.\"
+.\" ============================================================
+.\"
+パス \fI/proc/self\fP に対して \fBreadlink\fP(2) を呼び出すと、 procfs のマウントを行ったプロセスの PID
+名前空間におけるプロセス ID が得られる。 これは調査目的でプロセスが他の名前空間で自身の PID を知りたい場合などに役立つ。
+.SS その他
+プロセス ID が UNIX ドメインソケット経由で別の PID 名前空間のプロセスに渡される場合 (\fBunix\fP(7) の
+\fBSCM_CREDENTIALS\fP の説明を参照)、 プロセス ID は受信プロセスの PID 名前空間での対応する PID 値に翻訳される。
+.SH 準拠
+名前空間は Linux 独自の機能である。
+.SH 例
+\fBuser_namespaces\fP(7) 参照。
+.SH 関連項目
+\fBclone\fP(2), \fBsetns\fP(2), \fBunshare\fP(2), \fBproc\fP(5), \fBcredentials\fP(7),
+\fBcapabilities\fP(7), \fBuser_namespaces\fP(7), \fBswitch_root\fP(8)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
--- /dev/null
+.\" Copyright (C) 2014 Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (C) 2014 Peter Zijlstra <peterz@infradead.org>
+.\" and Copyright (C) 2014 Juri Lelli <juri.lelli@gmail.com>
+.\" Various pieces from the old sched_setscheduler(2) page
+.\" Copyright (C) Tom Bjorkholm, Markus Kuhn & David A. Wheeler 1996-1999
+.\" and Copyright (C) 2007 Carsten Emde <Carsten.Emde@osadl.org>
+.\" and Copyright (C) 2008 Michael Kerrisk <mtk.manpages@gmail.com>
+.\"
+.\" %%%LICENSE_START(GPLv2+_DOC_FULL)
+.\" This is free documentation; you can redistribute it and/or
+.\" modify it under the terms of the GNU General Public License as
+.\" published by the Free Software Foundation; either version 2 of
+.\" the License, or (at your option) any later version.
+.\"
+.\" The GNU General Public License's references to "object code"
+.\" and "executables" are to be interpreted as the output of any
+.\" document formatting or typesetting system, including
+.\" intermediate and printed output.
+.\"
+.\" This manual is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public
+.\" License along with this manual; if not, see
+.\" <http://www.gnu.org/licenses/>.
+.\" %%%LICENSE_END
+.\"
+.\" Worth looking at: http://rt.wiki.kernel.org/index.php
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH SCHED 7 2014\-10\-02 Linux "Linux Programmer's Manual"
+.SH 名前
+sched \- スケジューリング API の概要
+.SH 説明
+.SS "API の概要"
+Linux のスケジューリング API は以下のとおりである。
+.TP
+\fBsched_setscheduler\fP(2)
+指定されたスレッドのスケジューリングポリシーとパラメーターを設定する。
+.TP
+\fBsched_getscheduler\fP(2)
+指定されたスレッドのスケジューリングポリシーを返す。
+.TP
+\fBsched_setparam\fP(2)
+指定されたスレッドのスケジューリングパラメーターを設定する。
+.TP
+\fBsched_getparam\fP(2)
+指定されたスレッドのスケジューリングパラメーターを取得する。
+.TP
+\fBsched_get_priority_max\fP(2)
+指定されたスケジューリングポリシーで利用可能な最小の優先度を返す。
+.TP
+\fBsched_get_priority_min\fP(2)
+指定されたスケジューリングポリシーで利用可能な最大の優先度を返す。
+.TP
+\fBsched_rr_get_interval\fP(2)
+「ラウンドロビン」スケジューリングポリシーでスケジューリグされるスレッドで使用される単位時間 (quantum) を取得する。
+.TP
+\fBsched_yield\fP(2)
+呼び出し元が CPU の使用権を明け渡して、 他のスレッドが実行できるようにする。
+.TP
+\fBsched_setaffinity\fP(2)
+(Linux 固有) 指定されたスレッドの CPU affinity を設定する。
+.TP
+\fBsched_getaffinity\fP(2)
+(Linux 固有) 指定されたスレッドの CPU affinity を取得する。
+.TP
+\fBsched_setattr\fP(2)
+指定されたスレッドのスケジューリングポリシーとパラメーターを設定する。 この (Linux 固有の) システムコールは
+\fBsched_setscheduler\fP(2) と \fBsched_setparam\fP(2) の両方の機能を持つ。
+.TP
+\fBsched_getattr\fP(2)
+.\"
+指定されたスレッドのスケジューリングポリシーとパラメーターを取得する。 この (Linux 固有の) システムコールは
+\fBsched_getscheduler\fP(2) と \fBsched_getparam\fP(2) の両方の機能を持つ。
+.SS "スケジューリングポリシー (scheduling policy)"
+スケジューラ (scheduler) とはカーネルの構成要素で、 次に CPU で実行される実行可能なスレッドを決定するものである。
+各々のスレッドには、スケジューリングポリシーと 「静的」なスケジューリング優先度 \fIsched_priority\fP が対応付けられる。
+スケジューラは、システム上の全スレッドのスケジューリングポリシーと 静的優先度に関する知識に基づいて決定を行う。
+
+通常のスケジューリングポリシー (\fBSCHED_OTHER\fP, \fBSCHED_IDLE\fP, \fBSCHED_BATCH\fP)
+の下でスケジューリングされるスレッドでは、 \fIsched_priority\fP はスケジューリングの決定に使用されない
+(\fIsched_priority\fP には 0 を指定しなければならない)。
+
+リアルタイムスケジューリングポリシー (\fBSCHED_FIFO\fP, \fBSCHED_RR\fP) の下でスケジューリングされるスレッドは、
+\fIsched_priority\fP の値は 1 (最低) から 99 (最高) の範囲となる
+(数字から分かるように、リアルタイムスレッドは常に通常のスレッドよりも 高い優先度を持つ)。 ここで注意すべきなのは、POSIX.1\-2001
+が要求しているのは、 リアルタイムポリシーの実装において最低 32 種類の異なる優先度レベルが
+サポートされることだけであり、いくつかのシステムではこの最低限の数の 優先度しか提供されていない、ということである。 移植性が必要なプログラムでは、
+\fBsched_get_priority_min\fP(2) と \fBsched_get_priority_max\fP(2)
+を使って、あるポリシーがサポートする優先度の範囲を調べるべきである。
+
+概念としては、 スケジューラはその \fIsched_priority\fP の値それぞれに対して 実行可能なスレッドのリストを管理している。
+どのスレッドを次に実行するかを決定するために、 スケジューラは静的優先度の最も高い空でないリストを探して、 そのリストの先頭のスレッドを選択する。
+
+各スレッドのスケジューリングポリシーは、 そのスレッドが同じ静的優先度を持つスレッドのリストの中のどこに挿入され、
+このリストの中をどのように移動するかを決定する。
+
+全てのスケジューリングはプリエンプティブ (preemptive) である: より高い優先度のスレッドが実行可能になると、現在実行中のスレッドは実行権を
+取り上げられ (preempted)、そのスレッドの静的優先度レベルの待ちリストに 戻される。スケジューリングポリシーは同じ静的優先度を持つ実行可能な
+スレッドのリストの中で順番のみを決定する。
+.SS "SCHED_FIFO: ファーストインファーストアウトスケジューリング"
+\fBSCHED_FIFO\fP は 0 より大きな静的優先度でのみ使用できる。このポリシーでは、 \fBSCHED_FIFO\fP
+スレッドが実行可能になった場合、 そのポリシーが \fBSCHED_OTHER\fP、 \fBSCHED_BATCH\fP、 \fBSCHED_IDLE\fP の
+現在実行中のスレッドは直ちに実行権を取り上げられる。 \fBSCHED_FIFO\fP は時分割のない単純なスケジューリングアルゴリズムである。
+\fBSCHED_FIFO\fP ポリシーでスケジューリングされているスレッドには以下の ルールが適用される:
+.IP * 3
+より高い優先度の他のスレッドによって取って代わられた \fBSCHED_FIFO\fP スレッドはその優先度のリストの先頭に留まり続け、
+より高い優先度のスレッド全てが停止 (block) した場合に実行を再開する。
+.IP *
+\fBSCHED_FIFO\fP スレッドが実行可能になった時、その優先度のリストの最後 に挿入される。
+.IP *
+.\" In 2.2.x and 2.4.x, the thread is placed at the front of the queue
+.\" In 2.0.x, the Right Thing happened: the thread went to the back -- MTK
+\fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2), \fBsched_setattr\fP(2) は \fIpid\fP
+で指定された \fBSCHED_FIFO\fP (または \fBSCHED_RR\fP) スレッドが 実行可能な場合、リストの最初に置く。
+結果として、もし優先度が同じだった場合、 現在実行中のスレッドに先んじるかもしれない。 (POSIX.1\-2001
+ではスレッドはリストの最後に行くべきと規定されている。)
+.IP *
+\fBsched_yield\fP(2) を呼び出したスレッドはリストの最後に置かれる。
+.PP
+その他のイベントによって \fBSCHED_FIFO\fP
+ポリシーでスケジューリングされるスレッドが同じ優先度の実行可能なスレッドの待ちリストの中を移動することはない。
+
+\fBSCHED_FIFO\fP スレッドは I/O 要求によって停止するか、 より高い優先度のスレッドによって置きかえられるか、
+\fBsched_yield\fP(2) を呼び出すまで実行を続ける。
+.SS "SCHED_RR: ラウンドロビン (round\-robin)スケジューリング"
+.\" On Linux 2.4, the length of the RR interval is influenced
+.\" by the process nice value -- MTK
+.\"
+\fBSCHED_RR\fP は \fBSCHED_FIFO\fP の単純な拡張である。 上述された
+\fBSCHED_FIFO\fP に関する記述は全て \fBSCHED_RR\fP に 適用できる。異なるのは
+それぞれのスレッドは最大時間単位までしか実行できない ということである。
+\fBSCHED_RR\fP スレッドが時間単位と同じかそれより 長い時間実行されると、
+その優先度のリストの最後に置かれる。 より高い優先度のスレッドによって
+置きかえられ、その後実行を再開した \fBSCHED_RR\fP スレッドは、そのラウンド
+ロビン時間単位を完全に使い切る まで実行される。その時間単位の長さは
+\fBsched_rr_get_interval\fP(2) を使って取得できる。
+.SS "SCHED_DEADLINE: Sporadic task model deadline scheduling"
+バージョン 3.14 以降では、 Linux はデッドラインスケジューリングポリシー (\fBSCHED_DEADLINE\fP) が提供される。
+現在のところ、 このポリシーは GEDF (Global Earliest Deadline First) を使って CBS (Constant
+Bandwidth Server) との組み合わせで実装されている。 このポリシーと関連する属性の設定、取得を行うには、 Linux
+固有のシステムコール \fBsched_setattr\fP(2) と \fBsched_getattr\fP(2) を使用する必要がある。
+
+A sporadic task is one that has a sequence of jobs, where each job is
+activated at most once per period. Each job also has a \fIrelative
+deadline\fP, before which it should finish execution, and a \fIcomputation
+time\fP, which is the CPU time necessary for executing the job. The moment
+when a task wakes up because a new job has to be executed is called the
+\fIarrival time\fP (also referred to as the request time or release time). The
+\fIstart time\fP is the time at which a task starts its execution. The
+\fIabsolute deadline\fP is thus obtained by adding the relative deadline to the
+arrival time.
+
+The following diagram clarifies these terms:
+
+.in +4n
+.nf
+arrival/wakeup absolute deadline
+ | start time |
+ | | |
+ v v v
+\-\-\-\-\-x\-\-\-\-\-\-\-\-xooooooooooooooooo\-\-\-\-\-\-\-\-x\-\-\-\-\-\-\-\-x\-\-\-
+ |<\- comp. time \->|
+ |<\-\-\-\-\-\-\- relative deadline \-\-\-\-\-\->|
+ |<\-\-\-\-\-\-\-\-\-\-\-\-\-\- period \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\->|
+.fi
+.in
+
+When setting a \fBSCHED_DEADLINE\fP policy for a thread using
+\fBsched_setattr\fP(2), one can specify three parameters: \fIRuntime\fP,
+\fIDeadline\fP, and \fIPeriod\fP. These parameters do not necessarily correspond
+to the aforementioned terms: usual practice is to set Runtime to something
+bigger than the average computation time (or worst\-case execution time for
+hard real\-time tasks), Deadline to the relative deadline, and Period to the
+period of the task. Thus, for \fBSCHED_DEADLINE\fP scheduling, we have:
+
+.in +4n
+.nf
+arrival/wakeup absolute deadline
+ | start time |
+ | | |
+ v v v
+\-\-\-\-\-x\-\-\-\-\-\-\-\-xooooooooooooooooo\-\-\-\-\-\-\-\-x\-\-\-\-\-\-\-\-x\-\-\-
+ |<\-\- Runtime \-\-\-\-\-\-\->|
+ |<\-\-\-\-\-\-\-\-\-\-\- Deadline \-\-\-\-\-\-\-\-\-\-\->|
+ |<\-\-\-\-\-\-\-\-\-\-\-\-\-\- Period \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\->|
+.fi
+.in
+
+.\" FIXME It looks as though specifying sched_period as 0 means
+.\" "make sched_period the same as sched_deadline".
+.\" This needs to be documented.
+3 角デッドラインスケジューリングパラメーターは \fIsched_attr\fP 構造体の \fIsched_runtime\fP,
+\fIsched_deadline\fP, \fIsched_period\fP フィールドに対応する。 これらのフィールドはナノ秒単位の値である。
+\fIsched_period\fP に 0 が指定された場合 \fIsched_deadline\fP と同じ値になる。
+
+カーネルでは以下の関係が成り立つことが求められる。
+
+ sched_runtime <= sched_deadline <= sched_period
+
+.\" See __checkparam_dl in kernel/sched/core.c
+In addition, under the current implementation, all of the parameter values
+must be at least 1024 (i.e., just over one microsecond, which is the
+resolution of the implementation), and less than 2^63. If any of these
+checks fails, \fBsched_setattr\fP(2) fails with the error \fBEINVAL\fP.
+
+The CBS guarantees non\-interference between tasks, by throttling threads
+that attempt to over\-run their specified Runtime.
+
+To ensure deadline scheduling guarantees, the kernel must prevent situations
+where the set of \fBSCHED_DEADLINE\fP threads is not feasible (schedulable)
+within the given constraints. The kernel thus performs an admittance test
+when setting or changing \fBSCHED_DEADLINE\fP policy and attributes. This
+admission test calculates whether the change is feasible; if it is not
+\fBsched_setattr\fP(2) fails with the error \fBEBUSY\fP.
+
+For example, it is required (but not necessarily sufficient) for the total
+utilization to be less than or equal to the total number of CPUs available,
+where, since each thread can maximally run for Runtime per Period, that
+thread's utilization is its Runtime divided by its Period.
+
+In order to fulfil the guarantees that are made when a thread is admitted to
+the \fBSCHED_DEADLINE\fP policy, \fBSCHED_DEADLINE\fP threads are the highest
+priority (user controllable) threads in the system; if any \fBSCHED_DEADLINE\fP
+thread is runnable, it will preempt any thread scheduled under one of the
+other policies.
+
+A call to \fBfork\fP(2) by a thread scheduled under the \fBSCHED_DEADLINE\fP
+policy will fail with the error \fBEAGAIN\fP, unless the thread has its
+reset\-on\-fork flag set (see below).
+
+.\"
+.\" FIXME Calling sched_getparam() on a SCHED_DEADLINE thread
+.\" fails with EINVAL, but sched_getscheduler() succeeds.
+.\" Is that intended? (Why?)
+.\"
+A \fBSCHED_DEADLINE\fP thread that calls \fBsched_yield\fP(2) will yield the
+current job and wait for a new period to begin.
+.SS "SCHED_OTHER: Linux のデフォルトの時分割スケジューリング"
+.\"
+\fBSCHED_OTHER\fP は静的優先度 0 でのみ使用できる。 \fBSCHED_OTHER\fP は Linux 標準の時分割スケジューラで、
+特別なリアルタイム機構を必要としていない全てのスレッドで使用される。 実行するスレッドは、静的優先度 0 のリストから、このリストの中だけで
+決定される「動的な」優先度 (dynamic priority) に基いて決定される。 動的な優先度は (\fBnice\fP(2),
+\fBsetpriority\fP(2), \fBsched_setattr\fP(2) により設定される) nice 値に基づいて決定されるもので、
+単位時間毎に、スレッドが実行可能だが、スケジューラにより実行が拒否された 場合にインクリメントされる。 これにより、全ての \fBSCHED_OTHER\fP
+スレッドでの公平性が保証される。
+.SS "SCHED_BATCH: バッチプロセスのスケジューリング"
+(Linux 2.6.16 以降) \fBSCHED_BATCH\fP は静的優先度 0 でのみ使用できる。 このポリシーは (nice 値に基づく)
+動的な優先度にしたがってスレッドの スケジューリングが行われるという点で、\fBSCHED_OTHER\fP に似ている。
+異なるのは、このポリシーでは、スレッドが常に CPU に負荷のかかる (CPU\-intensive) 処理を行うと、スケジューラが仮定する点である。
+スケジューラはスレッドを呼び起こす毎にそのスレッドにスケジューリング上の ペナルティを少し課し、その結果、このスレッドはスケジューリングの決定で
+若干冷遇されるようになる。
+
+.\" The following paragraph is drawn largely from the text that
+.\" accompanied Ingo Molnar's patch for the implementation of
+.\" SCHED_BATCH.
+.\" commit b0a9499c3dd50d333e2aedb7e894873c58da3785
+.\"
+このポリシーは、非対話的な処理だがその nice 値を下げたくない処理や、 (処理のタスク間で) 余計なタスクの置き換えの原因とある対話的な処理なしで
+確定的な (deterministic) スケジューリングポリシーを適用したい処理に 対して有効である。
+.SS "SCHED_IDLE: 非常に優先度の低いジョブのスケジューリング"
+(Linux 2.6.23 以降) \fBSCHED_IDLE\fP は静的優先度 0 でのみ使用できる。 このポリシーではプロセスの nice
+値はスケジューリングに影響を与えない。
+
+.\"
+非常に低い優先度でのジョブの実行を目的としたものである (非常に低い優先度とは、ポリシー \fBSCHED_OTHER\fP か \fBSCHED_BATCH\fP
+での nice 値 +19 よりさらに低い優先度である)。
+.SS 子プロセスでのスケジューリングポリシーのリセット
+各スレッドには reset\-on\-fork スケジューリングフラグがある。 このフラグがセットされると、 \fBfork\fP(2)
+で作成される子プロセスは特権スケジューリングポリシーを継承しない。 reset\-on\-fork フラグは以下のいずれかの方法でセットできる。
+.IP * 3
+\fBsched_setscheduler\fP(2) を呼び出す際に \fBSCHED_RESET_ON_FORK\fP フラグを \fIpolicy\fP
+引き数に論理和で指定する (Linux 2.6.32 以降)。
+.IP *
+\fBsched_setattr\fP(2) を呼び出し際に \fIattr.sched_flags\fP に
+\fBSCHED_FLAG_RESET_ON_FORK\fP フラグを指定する。
+.PP
+これらの 2 つの API で使用される定数は名前が違っている点に注意すること。 同様に reset\-on\-fork フラグの状態は
+\fBsched_getscheduler\fP(2) と \fBsched_getattr\fP(2) を使って取得できる。
+
+reset\-on\-fork 機能はメディア再生アプリケーションでの利用を意図したものである。 複数の子プロセスを作成することで、 アプリケーションは
+\fBRLIMIT_RTTIME\fP リソース上限 (\fBgetrlimit\fP(2) を参照) を避けることができる。
+
+より正確には、 reset\-on\-fork フラグがセットされた場合、それ以降に作成される子プロセスに以下のルールが適用される。
+.IP * 3
+呼び出したスレッドのスケジューリングポリシーが \fBSCHED_FIFO\fP か \fBSCHED_RR\fP の場合、子プロセスのポリシーは
+\fBSCHED_OTHER\fP にリセットされる。
+.IP *
+子プロセスが負の nice 値を持っている場合、子プロセスの nice 値は 0 にリセットされる。
+.PP
+.\"
+一度 reset\-on\-fork フラグが有効にされた後は、このフラグをリセットできるのは、スレッドが \fBCAP_SYS_NICE\fP
+ケーパビリティを持つ場合だけである。このフラグは \fBfork\fP(2) で作成された子プロセスでは無効になる。
+.SS 特権とリソース制限
+2.6.12 より前のバージョンの Linux カーネルでは、 特権スレッド (\fBCAP_SYS_NICE\fP ケーパビリティを持つスレッド) だけが
+0 以外の静的優先度を設定する (すなわち、リアルタイムスケジューリングポリシーを設定する) ことができる。 非特権スレッドができる変更は
+\fBSCHED_OTHER\fP ポリシーを設定することだけであり、さらに、 この変更を行えるのは、 呼び出し元の実効ユーザ ID
+がポリシーの変更対象スレッド (\fIpid\fP で指定されたスレッド) の実ユーザ ID か実効ユーザ ID と 一致する場合だけである。
+
+\fBSCHED_DEADLINE\fP ポリシーを設定、変更するには、スレッドが特権 (\fBCAP_SYS_NICE\fP) を持っていなければならない。
+
+Linux 2.6.12 以降では、リソース制限 \fBRLIMIT_RTPRIO\fP が定義されており、 スケジューリングポリシーが
+\fBSCHED_RR\fP と \fBSCHED_FIFO\fP の場合の、非特権スレッドの静的優先度の上限を定めている。
+スケジューリングポリシーと優先度を変更する際のルールは以下の通りである。
+.IP * 3
+非特権スレッドに 0 以外の \fBRLIMIT_RTPRIO\fP ソフトリミットが設定されている場合、
+非特権スレッドはそのスレッドのスケジューリングポリシーと優先度を 変更できるが、優先度を現在の自身の優先度と \fBRLIMIT_RTPRIO\fP
+ソフトリミットの大きい方よりも高い値に設定できないという制限が課される。
+.IP *
+\fBRLIMIT_RTPRIO\fP ソフトリミットが 0 の場合、優先度を下げるか、 リアルタイムでないポリシーへ切り替えるかの変更だけが許可される。
+.IP *
+ある非特権スレッドが別のスレッドに対してこれらの変更を行う際にも、 同じルールが適用される。変更を行えるのは、変更を行おうとするスレッド の実効ユーザ
+ID が変更対象のスレッドの実ユーザ ID か実効ユーザ ID と 一致している場合に限られる。
+.IP *
+.\" commit c02aa73b1d18e43cfd79c2f193b225e84ca497c8
+\fBSCHED_IDLE\fP ポリシーの場合には特別なルールが適用される。 2.6.39 より前の Linux
+カーネルでは、このポリシーで動作する非特権スレッドは、 \fBRLIMIT_RTPRIO\fP
+リソース上限の値に関わらず、自分のポリシーを変更することができない。 2.6.39 以降の Linux カーネルでは、非特権スレッドは、自分の nice
+値が \fBRLIMIT_NICE\fP リソース上限 (\fBgetrlimit\fP(2) 参照)
+で許可された範囲である限りは、自分のスケジューリングポリシーを \fBSCHED_BATCH\fP か \fBSCHED_NORMAL\fP
+ポリシーに切り替えることができる。
+.PP
+特権スレッド (\fBCAP_SYS_NICE\fP ケーパビリティを持つスレッド) の場合、 \fBRLIMIT_RTPRIO\fP の制限は無視される;
+古いカーネルと同じように、スケジューリングポリシーと優先度に対し 任意の変更を行うことができる。 \fBRLIMIT_RTPRIO\fP
+に関するもっと詳しい情報は \fBgetrlimit\fP(2) を参照のこと。
+.SS "リアルタイムプロセスとデッドラインプロセスの CPU 使用量を制限する"
+\fBSCHED_FIFO\fP, \fBSCHED_RR\fP, \fBSCHED_DEADLINE\fP でスケジューリングされる
+スレッドが停止せずに無限ループに陥ると、 他の全てのより低い優先度のスレッドを永久に停止 (block) させてしまう。 Linux 2.6.25
+より前では、 リアルタイムプロセスが暴走してしまい、システムが止まってしまうのを防止する唯一の方法は、 (コンソールで)
+シェルをテスト対象のアプリケーションよりも高い静的優先度で実行することだけであった。 これによって期待通りに停止したり終了したりしないリアルタイム
+アプリケーションを緊急終了させることが可能になる。
+
+Linux 2.6.25 以降では、 暴走したリアルタイムプロセスやデッドラインプロセスを扱う別の方法が提供されている。 一つは
+\fBRLIMIT_RTTIME\fP リソース上限を使ってリアルタイムプロセスが消費できる CPU 時間の上限を設定する方法である。 詳細は
+\fBgetrlimit\fP(2) を参照。
+
+Linux 2.6.25 以降では、 2 つの \fI/proc\fP ファイルを使って、リアルタイムでないプロセスが使用できる CPU
+時間を一定量予約することができる。 この方法で CPU 時間をいくらか予約しておくことで、 CPU 時間が (例えば) root
+シェルに割り当てられ、このシェルから暴走したプロセスを殺すことができる。 これらのファイルでは両方ともマイクロ秒で時間を指定する。
+.TP
+\fI/proc/sys/kernel/sched_rt_period_us\fP
+このファイルは、 CPU 時間 100% にあたるスケジューリング間隔を指定する。 このファイルの値として 1 から \fBINT_MAX\fP
+を指定できる。 この値は実際の時間としては 1 マイクロ秒から約 35 分に相当する。 このファイルのデフォルト値は 1,000,000 (1 秒)
+である。
+.TP
+\fI/proc/sys/kernel/sched_rt_runtime_us\fP
+このファイルの値は、 システム上のリアルタイムスケジューリングやデッドラインスケジューリングの全プロセスが使用できる「期間」を指定する。
+このファイルの値として \-1 から \fBINT_MAX\fP\-1 を指定できる。 \-1 を指定すると、実行時間 (runtime) はスケジューリング間隔
+(period) と同じになる。 つまり、 CPU 時間はリアルタイムでないプロセスには確保されない (カーネル 2.6.25 より前の Linux
+の動作である)。 このファイルのデフォルト値は 950,000 (0.95 秒) である。 これは CPU 時間の 5%
+がリアルタイムやデッドラインスケジューリングポリシー以外で動作するプロセスに確保されるという意味する。
+.PP
+.SS "応答時間 (response time)"
+.\" as described in
+.\" .BR request_irq (9).
+I/O 待ちで停止したより高い優先度のスレッドは再びスケジューリングされる 前にいくらかの応答時間がかかる。デバイスドライバーを書く場合には "slow
+interrupt" 割り込みハンドラーを使用することで この応答時間を劇的に減少させることができる。
+.SS その他
+子プロセスは \fBfork\fP(2) の際に親プロセスのスケジューリングポリシーとパラメータを継承する。 \fBexecve\fP(2)
+の前後で、スケジューリングポリシーとパラメータは保持される。
+
+リアルタイムプロセスは大抵、ページングの待ち時間を避けるために \fBmlock\fP(2) や \fBmlockall\fP(2)
+を使ってメモリロックをしなければならない。
+.SH 注意
+.PP
+もともとは、標準の Linux は一般目的のオペレーティングシステムとして 設計されており、バックグラウンドプロセスや対話的アプリケーション、
+リアルタイム性の要求が厳しくないリアルタイムアプリケーション (普通はタイミングの応答期限 (deadline) を満たす必要があるアプリケーション)
+を扱うことができた。 Linux カーネル 2.6 では、 カーネルのプリエンプション (タスクの置き換え) が可能であり、 新たに導入された O(1)
+スケジューラにより、 アクティブなタスクの数に関わらずスケジューリングに必要な時間は 固定で確定的 (deterministic)
+であることが保証されている。 それにも関わらず、カーネル 2.6.17 までは 真のリアルタイムコンピューティングは実現できなかった。
+.SS "本流の Linux カーネルでのリアルタイム機能"
+.\" FIXME . Probably this text will need some minor tweaking
+.\" by about the time of 2.6.30; ask Carsten Emde about this then.
+カーネル 2.6.18 から現在まで、 Linux は徐々にリアルタイム機能を備えつつ
+あるが、 これらの機能のほとんどは、 Ingo Molnar, Thomas Gleixner,
+Steven Rostedt らによって開発された、 以前の \fIrealtime\-preempt\fP パッチ
+からのものである。 これらのパッチが本流のカーネルに完全にマージされるま
+では (マージの完了はカーネル 2.6.30 あたりの予定)、 最高のリアルタイム
+性能を達成するには realtime\-preempt パッチを 組み込まなければならない。
+これらのパッチは
+.in +4n
+.nf
+
+patch\-\fIkernelversion\fP\-rt\fIpatchversion\fP
+.fi
+.in
+.PP
+という名前で、
+.UR http://www.kernel.org\:/pub\:/linux\:/kernel\:/projects\:/rt/
+.UE
+からダウンロードできる。
+
+このパッチが適用されず、かつパッチの内容の本流のカーネルへのマージが 完了するまでは、カーネルの設定では \fBCONFIG_PREEMPT_NONE\fP,
+\fBCONFIG_PREEMPT_VOLUNTARY\fP, \fBCONFIG_PREEMPT_DESKTOP\fP の 3つのプリエンプションクラス
+(preemption class) だけが提供される。 これらのクラスでは、最悪の場合のスケジューリング遅延がそれぞれ
+全く減らない、いくらか減る、かなり減る。
+
+パッチが適用された場合、またはパッチの内容の本流のカーネルへのマージが 完了した後では、上記に加えて設定項目として
+\fBCONFIG_PREEMPT_RT\fP が利用可能になる。この項目を選択すると、 Linux は通常のリアルタイムオペレーティングシステムに変身する。
+この場合には、 FIFO と RR のスケジューリングポリシーは、 真のリアルタイム優先度を持つスレッドを最悪の場合のスケジューリング遅延が
+最小となる環境で動作させるために使われることになる。
+.SH 関連項目
+.ad l
+.nh
+\fBchrt\fP(1), \fBtaskset\fP(1), \fBgetpriority\fP(2), \fBmlock\fP(2), \fBmlockall\fP(2),
+\fBmunlock\fP(2), \fBmunlockall\fP(2), \fBnice\fP(2), \fBsched_get_priority_max\fP(2),
+\fBsched_get_priority_min\fP(2), \fBsched_getscheduler\fP(2),
+\fBsched_getaffinity\fP(2), \fBsched_getparam\fP(2), \fBsched_rr_get_interval\fP(2),
+\fBsched_setaffinity\fP(2), \fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2),
+\fBsched_yield\fP(2), \fBsetpriority\fP(2), \fBpthread_getaffinity_np\fP(3),
+\fBpthread_setaffinity_np\fP(3), \fBsched_getcpu\fP(3), \fBcapabilities\fP(7),
+\fBcpuset\fP(7)
+.ad
+.PP
+\fIProgramming for the real world \- POSIX.4\fP by Bill O. Gallmeister, O'Reilly
+& Associates, Inc., ISBN 1\-56592\-074\-0.
+.PP
+Linux カーネルソースのファイル \fIDocumentation/scheduler/sched\-deadline.txt\fP,
+\fIDocumentation/scheduler/sched\-rt\-group.txt\fP,
+\fIDocumentation/scheduler/sched\-design\-CFS.txt\fP,
+\fIDocumentation/scheduler/sched\-nice\-design.txt\fP
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
.RS 4
.IP * 2
.\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06
-\fBread\fP(2), \fBreadv\fP(2), \fBwrite\fP(2), \fBwritev\fP(2), and \fBioctl\fP(2) calls
-on "slow" devices. A "slow" device is one where the I/O call may block for
-an indefinite time, for example, a terminal, pipe, or socket. (A disk is
-not a slow device according to this definition.) A \fBread\fP(2) on an
-\fBeventfd\fP(2), \fBsignalfd\fP(2), \fBtimerfd\fP(2), \fBfanotify\fP(7), or
-\fBinotify\fP(7) file descriptor is also considered to be a "slow" operation.
-(Before Linux 3.8, reads from an \fBinotify\fP(7) file descriptor were not
-restartable; when interrupted by a signal handler, \fBread\fP(2) always failed
-with the error \fBEINTR\fP.) If an I/O call on a slow device has already
-transferred some data by the time it is interrupted by a signal handler,
-then the call will return a success status (normally, the number of bytes
-transferred).
+\fBread\fP(2), \fBreadv\fP(2), \fBwrite\fP(2), \fBwritev\fP(2), \fBioctl\fP(2) の「遅い
+(slow)」デバイスに対する呼び出し。 ここでいう「遅い」デバイスとは、I/O 呼び出しが無期限に停止 (block) する
+可能性のあるデバイスのことで、例としては端末、パイプ、ソケットがある (この定義では、ディスクは遅いデバイスではない)。 \fBeventfd\fP(2),
+\fBsignalfd\fP(2), \fBtimerfd\fP(2), \fBfanotify\fP(7), \fBinotify\fP(7)
+のファイルディスクリプタに対する \fBread\fP(2) も「遅い」操作と考えられる。 (Linux 3.8 より前であｈ， \fBinotify\fP(7)
+ファイルディスクリプタからの読み出しは再開できなかった。シグナルハンドラーによって割り込まれた場合、 \fBread\fP(2) は常にエラー
+\fBEINTR\fP で失敗していた。) 遅いデバイスに対する I/O 呼び出しが、 シグナルハンドラにより割り込まれた時点までに何らかのデータを
+すでに転送していれば、呼び出しは成功ステータス (通常は、転送されたバイト数) を返すことだろう。
.IP *
停止 (block) する可能性のある \fBopen\fP(2) (例えば、FIFO のオープン時; \fBfifo\fP(7) 参照)。
.IP *
.IP *
\fBfutex\fP(2) \fBFUTEX_WAIT\fP (Linux 2.6.22 以降; それ以前は常に \fBEINTR\fP で失敗していた)。
.IP *
-\fBpthread_mutex_lock\fP(3), \fBpthread_cond_wait\fP(3), and related APIs.
+\fBpthread_mutex_lock\fP(3), \fBpthread_cond_wait\fP(3) と関連 API。
.IP *
POSIX セマフォインターフェイス: \fBsem_wait\fP(3), \fBsem_timedwait\fP(3) (Linux 2.6.22 以降;
それ以前は常に \fBEINTR\fP で失敗していた)。
再スタートすることは決してない。 これらは、シグナルハンドラにより割り込まれると、常にエラー \fBEINTR\fP で失敗する。
.RS 4
.IP * 2
-"Input" socket interfaces, when a timeout (\fBSO_RCVTIMEO\fP) has been set on
-the socket using \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2),
-\fBrecvmmsg\fP(2) (also with a non\-NULL \fItimeout\fP argument), and
-\fBrecvmsg\fP(2).
+\fBsetsockopt\fP(2) を使ってタイムアウト (\fBSO_RCVTIMEO\fP) が設定されている「入力」ソケットインターフェース:
+\fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (NULL 以外の
+\fItimeout\fP 引き数も指定されている場合), \fBrecvmsg\fP(2)
.IP *
.\" FIXME . What about sendmmsg()?
-"Output" socket interfaces, when a timeout (\fBSO_SNDTIMEO\fP) has been set on
-the socket using \fBsetsockopt\fP(2): \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2),
-and \fBsendmsg\fP(2).
+\fBsetsockopt\fP(2) を使ってタイムアウト (\fBSO_SNDTIMEO\fP) が設定されているソケットインターフェース:
+\fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2), \fBsendmsg\fP(2)
.IP *
シグナル待ちに使われるインターフェイス: \fBpause\fP(2), \fBsigsuspend\fP(2), \fBsigtimedwait\fP(2),
\fBsigwaitinfo\fP(2).
この挙動を示す Linux のインターフェイスは以下の通りである。
.RS 4
.IP * 2
-"Input" socket interfaces, when a timeout (\fBSO_RCVTIMEO\fP) has been set on
-the socket using \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2),
-\fBrecvmmsg\fP(2) (also with a non\-NULL \fItimeout\fP argument), and
-\fBrecvmsg\fP(2).
+\fBsetsockopt\fP(2) を使ってタイムアウト (\fBSO_RCVTIMEO\fP) が設定されている「入力」ソケットインターフェース:
+\fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2) (NULL 以外の
+\fItimeout\fP 引き数も指定されている場合), \fBrecvmsg\fP(2)
.IP *
.\" FIXME . What about sendmmsg()?
-"Output" socket interfaces, when a timeout (\fBSO_SNDTIMEO\fP) has been set on
-the socket using \fBsetsockopt\fP(2): \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2),
-and \fBsendmsg\fP(2).
+\fBsetsockopt\fP(2) を使ってタイムアウト (\fBSO_SNDTIMEO\fP) が設定されているソケットインターフェース:
+\fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2), \fBsendmsg\fP(2)
.IP * 2
\fBepoll_wait\fP(2), \fBepoll_pwait\fP(2).
.IP *
.PP
\fIsun_family\fP フィールドには必ず \fBAF_UNIX\fP が入っている。
-Various systems calls (for example, \fBbind\fP(2), \fBconnect\fP(2), and
-\fBsendto\fP(2)) take a \fIsockaddr_un\fP argument as input. Some other system
-calls (for example, \fBgetsockname\fP(2), \fBgetpeername\fP(2), \fBrecvfrom\fP(2),
-and \fBaccept\fP(2)) return an argument of this type.
+様々なシステムコール (例えば \fBbind\fP(2), \fBconnect\fP(2), \fBsendto\fP(2)) は入力として
+\fIsockaddr_un\fP 引き数を取る。 他のいくつかのシステムコール (例えば \fBgetsockname\fP(2),
+\fBgetpeername\fP(2), \fBrecvfrom\fP(2), \fBaccept\fP(2)) はこの型の引き数を返す。
\fIsockaddr_un\fP 構造体では 3 種類のアドレスが区別される。
.IP * 3
\fIsizeof(sa_family_t)\fP の値と同じだが、 他の実装では \fIsun_path\fP の前に他のフィールドが含まれる場合もある。
そのため、 \fBoffsetof\fP() 式を使う方がより移植性のある方法でアドレス構造体のサイズを知ることができる。)
.IP
-For further details of pathname sockets, see below.
+パス名ソケットの詳細については、後で説明する。
.IP *
.\" There is quite some variation across implementations: FreeBSD
.\" says the length is 16 bytes, HP-UX 11 says it's zero bytes.
より大きく)、 ソケットの名前は \fIsun_path\fP の最初の \fI(addrlen \- sizeof(sa_family_t))\fP
バイトに格納される。 ソケットの抽象名前空間は Linux による拡張であり、移植性はない。
.SS パス名ソケット
-When binding a socket to a pathname, a few rules should be observed for
-maximum portability and ease of coding:
+ソケットにパス名を結びつける際に、 最大限の移植性を持たせ、コーディングを簡単にするためのルールがいくつかある。
.IP * 3
\fIsun_path\fP のパス名はヌル終端すべきである。
.IP *
終端のヌルバイトを含めたパス名の長さは \fIsun_path\fP の大きさを超えないようにすべきである。
.IP *
-The \fIaddrlen\fP argument that describes the enclosing \fIsockaddr_un\fP
-structure should have a value of at least:
+\fIsockaddr_un\fP 構造体の終わりを示す \fIaddrlen\fP 引き数は最低でも以下の値を持つべきである。
.nf
offsetof(struct sockaddr_un, sun_path)+strlen(addr.sun_path)+1
.fi
.IP
-or, more simply, \fIaddrlen\fP can be specified as \fIsizeof(struct
-sockaddr_un)\fP.
+もしくは、もっと簡単には、 \fIaddrlen\fP に \fIsizeof(struct sockaddr_un)\fP を指定することもできる。
.PP
.\" Linux does this, including for the case where the supplied path
.\" is 108 bytes
-There is some variation in how implementations handle UNIX domain socket
-addresses that do not follow the above rules. For example, some (but not
-all) implementations append a null terminator if none is present in the
-supplied \fIsun_path\fP.
+UNIX ドメインソケットアドレスの扱いが上記のルールに従っていない実装もいくつかある。 (全部ではないが) いくつかの実装では、
+\fIsun_path\fP に文字列終端の NULL がなかった場合に終端の NULL が追加される。
.\" HP-UX
.\" Modern BSDs generally have 104, Tru64 and AIX have 104,
.\" Solaris and Irix have 108
-When coding portable applications, keep in mind that some implementations
-have \fIsun_path\fP as short as 92 bytes.
-
-Various system calls (\fBaccept\fP(2), \fBrecvfrom\fP(2), \fBgetsockname\fP(2),
-\fBgetpeername\fP(2)) return socket address structures. When applied to UNIX
-domain sockets, the value\-result \fIaddrlen\fP argument supplied to the call
-should be initialized as above. Upon return, the argument is set to
-indicate the \fIactual\fP size of the address structure. The caller should
-check the value returned in this argument: if the output value exceeds the
-input value, then there is no guarantee that a null terminator is present in
-\fIsun_path\fP. (See BUGS.)
+移植性があるアプリケーションを作成する際には、 いくつかの実装では \fIsun_path\fP は 92 バイトしかないという点にも留意しておくとよい。
+
+様々なシステムコール (\fBaccept\fP(2), \fBrecvfrom\fP(2), \fBgetsockname\fP(2),
+\fBgetpeername\fP(2)) がソケットアドレス構造体を返す。 これらのシステムコールが UNIX ドメインソケットに対して呼ばれた際には、
+これらの呼び出しに渡す \fIaddrlen\fP 引き数は上記の説明のように初期化すべきである。
+リターン時には、この引き数にはアドレス構造体の「実際の」サイズが設定される。 呼び出し側ではこの引き数で返された値を確認すべきである。
+返された値が入力値よりも大きい場合、 \fIsun_path\fP に終端の NULL バイトが存在する保証はない (「バグ」を参照)。
.SS ソケットオプション
歴史的な理由により、これらのオプションは たとえ \fBAF_UNIX\fP 固有のオプションであっても \fBSOL_SOCKET\fP 型で指定する。
ソケットファミリーとして \fBSOL_SOCKET\fP を指定すると、 \fBsetsockopt\fP(2) でオプションが設定でき、
UNIX ドメインのストリーム・ソケットでは、 帯域外データの概念はサポートされない。
.SH バグ
.\" The behavior on Solaris is quite similar.
-When binding a socket to an address, Linux is one of the implementations
-that appends a null terminator if none is supplied in \fIsun_path\fP. In most
-cases this is unproblematic: when the socket address is retrieved, it will
-be one byte longer than that supplied when the socket was bound. However,
-there is one case where confusing behavior can result: if 108 non\-null bytes
-are supplied when a socket is bound, then the addition of the null
-terminator takes the length of the pathname beyond \fIsizeof(sun_path)\fP.
-Consequently, when retrieving the socket address (for example, via
-\fBaccept\fP(2)), if the input \fIaddrlen\fP argument for the retrieving call is
-specified as \fIsizeof(struct sockaddr_un)\fP, then the returned address
-structure \fIwon't\fP have a null terminator in \fIsun_path\fP.
+ソケットをアドレスに結びつける際、 Linux は終端の NULL が \fIsun_path\fP になかった場合に追加する実装の一つである。
+ほとんどの場合、 これは問題にならない。 ソケットアドレスが取得された際、ソケットをバインドしたときに指定したものより 1 バイト長くなるだけである。
+しかしながら、紛らわしい動作が起こる場合が一つある。 ソケットをバインドした際に 108 個の NULL でないバイトを指定した場合、 終端の NULL
+が追加されるとパス名の長さが \fIsizeof(sun_path)\fP を超えてしまう。 結果として、(例えば \fBaccept\fP(2) で)
+ソケットアドレスを取得した際に、 値を取得する呼び出しの入力の \fIaddress\fP 引き数に \fIsizeof(struct
+sockaddr_un)\fP を指定したとすると、 返されるアドレス構造体は \fIsun_path\fP に終端の NULL を「含まない」ことになる。
.\" i.e., traditional BSD
-In addition, some implementations don't require a null terminator when
-binding a socket (the \fIaddrlen\fP argument is used to determine the length of
-\fIsun_path\fP) and when the socket address is retrieved on these
-implementations, there is no null terminator in \fIsun_path\fP.
+さらに、 いくつかの実装では、ソケットをバインドする際に終端の NULL が必要ではなく (\fIaddrlen\fP 引き数を使って \fIsun_path\fP
+の長さが判定される)、 このような実装でソケットアドレスを取得する際には、 \fIsun_path\fP に終端の NULL は存在しない。
-Applications that retrieve socket addresses can (portably) code to handle
-the possibility that there is no null terminator in \fIsun_path\fP by
-respecting the fact that the number of valid bytes in the pathname is:
+ソケットアドレスを取得するアプリケーションでは、 \fIsun_path\fP に終端の NULL が存在しないという移植性の問題を、
+パス名の有効なバイト数が以下のようになると事実を考慮することで取り扱うことができる。
.\" The following patch to amend kernel behavior was rejected:
.\" http://thread.gmane.org/gmane.linux.kernel.api/2437
.\" FIXME . Track http://austingroupbugs.net/view.php?id=561
strnlen(addr.sun_path, addrlen \- offsetof(sockaddr_un, sun_path))
-Alternatively, an application can retrieve the socket address by allocating
-a buffer of size \fIsizeof(struct sockaddr_un)+1\fP that is zeroed out before
-the retrieval. The retrieving call can specify \fIaddrlen\fP as
-\fIsizeof(struct sockaddr_un)\fP, and the extra zero byte ensures that there
-will be a null terminator for the string returned in \fIsun_path\fP:
+他の方法としては、 アプリケーションがソケットアドレスを取得する際、 取得の呼び出しを行う前に、 大きさが \fIsizeof(struct
+sockaddr_un)+1\fP のバッファーを割り当てることもできる。 取得の呼び出しでは \fIaddrlen\fP に \fIsizeof(struct
+sockaddr_un)\fP を指定すると、 余分な一つの 0 バイトにより \fIsun_path\fP で返される文字列に終端の NULL
+が含まれることが保証される。
.nf
.in +3
.in
.fi
-This sort of messiness can be avoided if it is guaranteed that the
-applications that \fIcreate\fP pathname sockets follow the rules outlined above
-under \fIPathname sockets\fP.
+アプリケーションが「パス名ソケット」の節で説明したルールにしたがってパス名を「作成」していれば、 このような分かりにくさは避けることができる。
.SH 例
\fBbind\fP(2) 参照。
＠:LDP man-pages:3.76:2010/11/22:getresgid32:2:getresgid:2:
○:LDP man-pages:3.76:2010/11/22:getresuid:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2010/11/22:getresuid32:2:getresuid:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/10/02:getrlimit:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/02:getrlimit:2:2015/01/09::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/05/10:getrusage:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2010/09/26:getsid:2:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
○:LDP man-pages:3.76:2008/12/03:getsockname:2:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2014/09/21:oldolduname:2:uname:2:
＠:LDP man-pages:3.76:2014/08/19:oldstat:2:stat:2:
＠:LDP man-pages:3.76:2014/09/21:olduname:2:uname:2:
-â\98\86:LDP man-pages:3.65=>3.76:2014/12/31:open:2:2014/04/28::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:open:2:2015/01/09::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2014/06/13:open_by_handle_at:2:::::
＠:LDP man-pages:3.76:2014/12/31:openat:2:open:2:
○:LDP man-pages:3.76:2012/12/31:outb:2:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
＠:LDP man-pages:3.76:2014/10/15:pwritev:2:readv:2:
○:LDP man-pages:3.76:2014/05/10:query_module:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2010/06/16:quotactl:2:::::
-â\98\86:LDP man-pages:3.65=>3.76:2014/05/04:read:2:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/05/04:read:2:2015/01/09::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/03/15:readahead:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/06/21:readdir:2:2015/01/05::hanataka@abyss.rim.or.jp:HANATAKA Shinya:
○:LDP man-pages:3.76:2014/10/15:readlink:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:recvmsg:2:recv:2:
☆:LDP man-pages:3.65=>3.76:2014/05/28:remap_file_pages:2:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/02/06:removexattr:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.65=>3.76:2014/08/19:rename:2:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/08/19:rename:2:2015/01/09::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:renameat:2:rename:2:
＠:LDP man-pages:3.76:2014/08/19:renameat2:2:rename:2:
×:LDP man-pages:3.76:2010/02/25:request_key:2:::::
○:LDP man-pages:3.76:2014/05/12:sched_get_priority_max:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/05/12:sched_get_priority_min:2:sched_get_priority_max:2:
＠:LDP man-pages:3.76:2014/12/31:sched_getaffinity:2:sched_setaffinity:2:
-※:LDP man-pages:3.76:2014/10/02:sched_getattr:2:sched_setattr:2:
+＠:LDP man-pages:3.76:2014/10/02:sched_getattr:2:sched_setattr:2:
＠:LDP man-pages:3.76:2014/05/11:sched_getparam:2:sched_setparam:2:
＠:LDP man-pages:3.76:2014/10/02:sched_getscheduler:2:sched_setscheduler:2:
○:LDP man-pages:3.76:2014/04/28:sched_rr_get_interval:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/12/31:sched_setaffinity:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
-×:LDP man-pages:3.76:2014/10/02:sched_setattr:2:::::
+○:LDP man-pages:3.76:2014/10/02:sched_setattr:2:2015/01/09::amotoki@gmail.com:Akihiro Motoki:
○:LDP man-pages:3.76:2014/05/11:sched_setparam:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.65=>3.76:2014/10/02:sched_setscheduler:2:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/02:sched_setscheduler:2:2015/01/09::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/04/28:sched_yield:2:2015/01/05::hanataka@abyss.rim.or.jp:HANATAKA Shinya:
＠:LDP man-pages:3.76:2013/02/12:security:2:unimplemented:2:
○:LDP man-pages:3.76:2014/12/31:select:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/09/23:wait4:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:waitid:2:wait:2:
＠:LDP man-pages:3.76:2014/08/19:waitpid:2:wait:2:
-â\98\86:LDP man-pages:3.65=>3.76:2014/05/04:write:2:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/05/04:write:2:2015/01/09::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/10/15:writev:2:readv:2:
＠:LDP man-pages:3.76:2007/12/28:CIRCLEQ_ENTRY:3:queue:3:
＠:LDP man-pages:3.76:2007/12/28:CIRCLEQ_HEAD:3:queue:3:
＠:LDP man-pages:3.76:2008/08/11:pow10l:3:pow10:3:
＠:LDP man-pages:3.76:2014/12/31:powf:3:pow:3:
＠:LDP man-pages:3.76:2014/12/31:powl:3:pow:3:
-â\98\86:LDP man-pages:3.68=>3.76:2014/07/08:printf:3:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:printf:3:2015/01/09::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/07/08:profil:3:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
○:LDP man-pages:3.76:2006/04/29:program_invocation_name:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2006/04/29:program_invocation_short_name:3:program_invocation_name:3:
○:LDP man-pages:3.76:2011/09/09:operator:7:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
○:LDP man-pages:3.76:2014/08/19:packet:7:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2009/12/05:path_resolution:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-×:LDP man-pages:3.76:2014/09/21:pid_namespaces:7:::::
+○:LDP man-pages:3.76:2014/09/21:pid_namespaces:7:2015/01/09::amotoki@gmail.com:Akihiro Motoki:
○:LDP man-pages:3.76:2014/07/08:pipe:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2007/12/21:posixoptions:7:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
○:LDP man-pages:3.76:2014/05/21:pthreads:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/05/13:sem_overview:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2010/09/10:shm_overview:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2011/09/09:sigevent:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:signal:7:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:signal:7:2015/01/09::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/07/08:socket:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2007/12/20:spufs:7:::::
○:LDP man-pages:3.76:2014/01/15:standards:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/07/08:udplite:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/06/13:unicode:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/08/05:units:7:2015/01/05::nakano@apm.seikei.ac.jp:NAKANO Takeo:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:unix:7:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:unix:7:2015/01/09::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/03/18:uri:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/03/18:url:7:uri:7:
＠:LDP man-pages:3.76:2014/03/18:urn:7:uri:7:
OSDN Git Service
