-.\" Hey Emacs! This file is -*- nroff -*- source.
-.\"
.\" Copyright (c) 1992 Drew Eckhardt <drew@cs.colorado.edu>, March 28, 1992
-.\" and Copyright (c) Michael Kerrisk, 2001, 2002, 2005
+.\" and Copyright (c) Michael Kerrisk, 2001, 2002, 2005, 2013
+.\"
+.\" %%%LICENSE_START(GPL_NOVERSION_ONELINE)
.\" May be distributed under the GNU General Public License.
+.\" %%%LICENSE_END
+.\"
.\" Modified by Michael Haardt <michael@moria.de>
.\" Modified 24 Jul 1993 by Rik Faith <faith@cs.unc.edu>
.\" Modified 21 Aug 1994 by Michael Chastain <mec@shell.portal.com>:
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
-.TH CLONE 2 2011\-09\-08 Linux "Linux Programmer's Manual"
+.\"
+.\" Japanese Version Copyright (c) 2001 HANATAKA Shinya
+.\" and Copyright(c) 2002, 2005-2008 Akihiro MOTOKI
+.\" Translated 2001-08-17, HANATAKA Shinya <hanataka@abyss.rim.or.jp>
+.\" Modified 2002-09-24, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>
+.\" Modified 2005-02-02, Akihiro MOTOKI
+.\" Updated 2005-04-17, Akihiro MOTOKI
+.\" Updated 2005-09-10, Akihiro MOTOKI
+.\" Updated 2006-03-05, Akihiro MOTOKI, LDP v2.25
+.\" Updated 2007-01-05, Akihiro MOTOKI, LDP v2.43
+.\" Updated 2007-05-01, Akihiro MOTOKI, LDP v2.46
+.\" Updated 2007-06-13, Akihiro MOTOKI, LDP v2.55
+.\" Updated 2008-08-04, Akihiro MOTOKI, LDP v3.05
+.\" Updated 2008-11-09, Akihiro MOTOKI, LDP v3.10
+.\" Updated 2009-03-02, Akihiro MOTOKI, LDP v3.19
+.\" Updated 2010-04-11, Akihiro MOTOKI, LDP v3.24
+.\" Updated 2012-05-08, Akihiro MOTOKI <amotoki@gmail.com>
+.\" Updated 2013-05-06, Akihiro MOTOKI <amotoki@gmail.com>
+.\"
+.TH CLONE 2 2014\-02\-27 Linux "Linux Programmer's Manual"
.SH 名前
clone, __clone2 \- 子プロセスを作成する
.SH 書式
.nf
-.\" Actually _BSD_SOURCE || _SVID_SOURCE
-.\" FIXME See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4749
-\fB#define _GNU_SOURCE\fP /* feature_test_macros(7) 参照 */
+/* glibc ラッパー関数のプロトタイプ */
+
\fB#include <sched.h>\fP
\fBint clone(int (*\fP\fIfn\fP\fB)(void *), void *\fP\fIchild_stack\fP\fB,\fP
\fB int \fP\fIflags\fP\fB, void *\fP\fIarg\fP\fB, ... \fP
\fB /* pid_t *\fP\fIptid\fP\fB, struct user_desc *\fP\fItls\fP\fB, pid_t *\fP\fIctid\fP\fB */ );\fP
+
+/* 素のシステムコールのプロトタイプ */
+
+\fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIchild_stack\fP\fB,\fP
+\fB void *\fP\fIptid\fP\fB, void *\fP\fIctid\fP\fB,\fP
+\fB struct pt_regs *\fP\fIregs\fP\fB);\fP
.fi
+.sp
+.in -4n
+glibc ラッパー関数の機能検査マクロの要件 (\fBfeature_test_macros\fP(7) 参照):
+.in
+.sp
+\fBclone\fP():
+.ad l
+.RS 4
+.PD 0
+.TP 4
+glibc 2.14 以降:
+_GNU_SOURCE
+.TP 4
+.\" See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4749
+glibc 2.14 より前:
+_BSD_SOURCE || _SVID_SOURCE
+ /* _GNU_SOURCE も定義される */
+.PD
+.RE
+.ad b
.SH 説明
-\fBclone\fP() は \fBfork\fP(2) と同じような方法で新しいプロセスを作成する。 \fBclone\fP()
-には、ライブラリ関数とその下層にあたる \fBclone\fP() システムコールが存在する。以下の説明では、システムコールの方を \fBsys_clone\fP
-と表すこととする。 \fBsys_clone\fP に関する説明はこのマニュアルの最後の方にある。
+\fBclone\fP() は、 \fBfork\fP(2) と似た方法で新しいプロセスを作成する。
+
+このページでは、 glibc の \fBclone\fP() ラッパー関数とその裏で呼ばれるシステムコールの両方について説明している。
+メインの説明はラッパー関数に関するものである。 素のシステムコールにおける差分はこのページの最後の方で説明する。
-\fBfork\fP(2) とは異なり、これらのコールでは、子プロセス (child process) と呼び出し元のプロセスとが、メモリ空間、
-ファイルディスクリプタのテーブル、シグナル・ハンドラのテーブルなどの 実行コンテキストの一部を共有できる。
+\fBfork\fP(2) とは異なり、\fBclone\fP() では、子プロセス (child process)
+ã\81¨å\91¼ã\81³å\87ºã\81\97å\85\83ã\81®ã\83\97ã\83ã\82»ã\82¹ã\81¨ã\81\8cã\80\81ã\83¡ã\83¢ã\83ªç©ºé\96\93ã\80\81ã\83\95ã\82¡ã\82¤ã\83«ã\83\87ã\82£ã\82¹ã\82¯ã\83ªã\83\97ã\82¿ã\81®ã\83\86ã\83¼ã\83\96ã\83«ã\80\81ã\82·ã\82°ã\83\8aã\83«ã\83»ã\83\8fã\83³ã\83\89ã\83©ã\81®ã\83\86ã\83¼ã\83\96ã\83«ã\81ªã\81©ã\81® å®\9fè¡\8cã\82³ã\83³ã\83\86ã\82ã\82¹ã\83\88ã\81®ä¸\80é\83¨ã\82\92å\85±æ\9c\89ã\81§ã\81\8dã\82\8bã\80\82
(このマニュアルにおける「呼び出し元のプロセス」は、通常は 「親プロセス」と一致する。但し、後述の \fBCLONE_PARENT\fP の項も参照のこと)
\fBclone\fP() の主要な使用法はスレッド (threads) を実装することである:
\fBCLONE_CHILD_SETTID\fP (Linux 2.5.49 以降)
子プロセスのメモリ内の \fIctid\fP が指す場所に子プロセスのスレッド ID を格納する。
.TP
-\fBCLONE_FILES\fP
+\fBCLONE_FILES\fP (Linux 2.0 以降)
\fBCLONE_FILES\fP が設定された場合、呼び出し元のプロセスと子プロセスはファイルディスクリプタの テーブルを共有する。
呼び出し元プロセスとその子プロセスの一方が作成した ファイルディスクリプタは、もう一方においても有効である。
同じように、一方のプロセスがファイルディスクリプタを閉じたり、 (\fBfcntl\fP(2) \fBF_SETFD\fP 操作を使って)
参照) を参照する)。 これ以降に、呼び出し元のプロセスと子プロセスの一方が ファイルディスクリプタの操作 (ファイルディスクリプタの
オープン・クローズや、ファイルディスクリプタ・フラグの変更) を行っても、もう一方のプロセスには影響を与えない。
.TP
-\fBCLONE_FS\fP
+\fBCLONE_FS\fP (Linux 2.0 以降)
\fBCLONE_FS\fP が設定された場合、呼び出し元のプロセスと子プロセスが同じファイル・システム
情報を共有する。ファイル・システム情報は、ファイル・システムのルート (root)、 カレント・ワーキング・ディレクトリ (current
working directory) や umask などである。 呼び出し元のプロセスや子プロセスのどちらか一方によって \fBchroot\fP(2),
このフラグが設定されていない場合、 (\fBfork\fP(2) の場合と同様) 呼び出し元のプロセスと同じ IPC 名前空間でプロセスが 作成される。
このフラグは、コンテナの実装での使用を意図して用意されたものである。
-IPC 名前空間は、System V IPC オブジェクト用の識別子 (identifiers) の 集合で構成される (System V IPC
-オブジェクトは \fBmsgctl\fP(2), \fBsemctl\fP(2), \fBshmctl\fP(2) を使って作成される)。 ある IPC
-名前空間に作成されたオブジェクトは、 その名前空間のメンバーである他のすべてのプロセスからも見えるが、 違う IPC 名前空間のプロセスからは見えない。
+.\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f
+.\" https://lwn.net/Articles/312232/
+IPC 名前空間は、独立の System\ V IPC オブジェクト空間 (\fBsvipc\fP(7) 参照) を提供する 。 (Linux 2.6.30
+以降では) 独立した POSIX メッセージキュー空間 (\fBmq_overview\fP(7) 参照) も提供される。 これらの IPC
+機構に共通の特徴として、 IPC オブジェクトはファイルシステムのパス名とは違った仕組みで識別されるという点がある。
+
+ある IPC 名前空間に作成されたオブジェクトは、 その名前空間のメンバーである他のすべてのプロセスからも見えるが、 違う IPC
+名前空間のプロセスからは見えない。
IPC 名前空間が破棄される時 (すなわち、その名前空間のメンバーの最後のプロセスが終了する時)、 その名前空間の全ての IPC
オブジェクトは自動的に破棄される。
.TP
\fBCLONE_NEWNET\fP (Linux 2.6.24 以降)
.\" FIXME Check when the implementation was completed
-(このフラグの実装は、Linux 2.6.29 あたりまでに完成した。)
+(このフラグの実装は、Linux 2.6.29 あたりまでには完成した。)
\fBCLONE_NEWNET\fP が設定された場合、新しいネットワーク名前空間 (network namaspace) でプロセスを作成する。
このフラグが設定されていない場合、 (\fBfork\fP(2) の場合と同様) 呼び出し元のプロセスと同じネットワーク名前空間でプロセスが 作成される。
このフラグは、コンテナの実装での使用を意図して用意されたものである。
+.\" FIXME Add pointer to veth(4) page when it is eventually completed
ネットワーク名前空間は、分離されたネットワークスタックを提供するものである (ネットワークスタックとは、 ネットワークデバイスインタフェース、IPv4
や IPv6 プロトコルスタック、 \fI/proc/net\fP、 \fI/sys/class/net\fP ディレクトリツリー、ソケットなどである)。
物理ネットワークデバイスが所属できるネットワーク名前空間は一つだけである。 仮想ネットワークデバイス ("veth") のペアにより パイプ風の抽象化
で作成される。これはシステムをハッキングするのには便利だが、 それ以外にはあまり使われない。 Linux 2.3.21 以降では、
システムのブートプロセス (PID 0) だけがこのフラグを指定できる。 Linux 2.5.16 で削除された。
.TP
-\fBCLONE_PTRACE\fP
+\fBCLONE_PTRACE\fP (Linux 2.2 以降)
\fBCLONE_PTRACE\fP が指定され、かつ呼び出し元のプロセスが追跡 (trace) されていた場合、子プロセスも 同様に追跡される。
(\fBptrace\fP(2) を参照のこと)
.TP
\fInewtls\fP 引き数は、新しい TLS (Thread Local Storage) ディスクリプタである。
(\fBset_thread_area\fP(2) を参照のこと)
.TP
-\fBCLONE_SIGHAND\fP
+\fBCLONE_SIGHAND\fP (Linux 2.0 以降)
\fBCLONE_SIGHAND\fP が設定された場合、呼び出し元のプロセスと子プロセスは同じシグナル・ハン
ドラのテーブルを共有する。呼び出し元のプロセスまたは子プロセスのどちらかが \fBsigaction\fP(2)
を呼び出してシグナルに対応する動作を変更した場合、 もう一方のプロセスのシグナル動作も変更される。 但し、呼び出し元のプロセスと子プロセスは、
Linux 2.6.38 で完全に\fI削除\fPされた。
.TP
\fBCLONE_SYSVSEM\fP (Linux 2.5.10 以降)
-\fBCLONE_SYSVSEM\fP がセットされると、子プロセスと呼び出し元プロセスは一つの System V セマフォのアンドゥ値リスト
+\fBCLONE_SYSVSEM\fP がセットされると、子プロセスと呼び出し元プロセスは一つの System\ V セマフォのアンドゥ値リスト
(\fBsemop\fP(2) 参照) を共有する。このフラグがセットされていなければ、 子プロセスは独自のアンドゥリストを持つ
(リストの初期値は空である)。
.TP
その子供を \fBwait\fP(2) できる。
Linux 2.5.35 以降では、 \fBCLONE_THREAD\fP を指定する場合、 \fIflags\fP に \fBCLONE_SIGHAND\fP
-も含まれていなければならない。
+も含まれていなければならない (Linux 2.6.0\-test6 以降では、 \fBCLONE_SIGHAND\fP を指定する場合 \fBCLONE_VM\fP
+も指定する必要がある点に注意すること)。
\fBkill\fP(2) を使ってスレッド・グループ全体 (つまり TGID) にシグナルを送ることもできれば、 \fBtgkill\fP(2)
を使って特定のスレッド (つまり TID) にシグナルを送ることもできる。
\fBCLONE_UNTRACED\fP が指定されると、 trace を行っているプロセスは この子プロセスに \fBCLONE_PTRACE\fP
を適用することができない。
.TP
-\fBCLONE_VFORK\fP
+\fBCLONE_VFORK\fP (Linux 2.2 以降)
\fBCLONE_VFORK\fP が設定された場合、 (\fBvfork\fP(2) と同様に) 子プロセスが \fBexecve\fP(2) または
\fB_exit\fP(2) によって仮想メモリを解放するまで、呼び出し元のプロセスの実行は停止される。
\fBCLONE_VFORK\fP が設定されていない場合、 \fBclone\fP() 呼び出し後は、呼び出し元のプロセスと子プロセスの
両方がスケジュール対象となり、アプリケーションはこれらのプロセスの 実行順序に依存しないようにすべきである。
.TP
-\fBCLONE_VM\fP
+\fBCLONE_VM\fP (Linux 2.0 以降)
\fBCLONE_VM\fP が設定された場合、呼び出し元のプロセスと子プロセスは同じメモリ空間で
実行される。特に、呼び出し元のプロセスや子プロセスの一方がメモリに 書き込んだ内容はもう一方のプロセスからも見ることができる。さらに、
子プロセスや呼び出し元のプロセスの一方が \fBmmap\fP(2) や \fBmunmap\fP(2) を使ってメモリをマップしたりアンマップした場合、
\fBCLONE_VM\fP が設定されていない場合、子プロセスは \fBclone\fP() が実行された時点での、親プロセスのメモリ空間をコピーした
別のメモリ空間で実行される。 一方のプロセスが行ったメモリへの書き込みや ファイルのマップ/アンマップは、 \fBfork\fP(2)
の場合と同様、もう一方のプロセスには影響しない。
-.SS sys_clone
-\fBsys_clone\fP システムコールは、より \fBfork\fP(2) に近いかたちになっており、子プロセスの実行が呼び出しが行われた場所から
-続けられる。 そのため、 \fBsys_clone\fP が必要とする引き数は \fIflags\fP と \fIchild_stack\fP だけであり、それらは
-\fBclone\fP() と同じ意味を持つ (これらの引き数の順番は \fBclone\fP() とは異なることに注意せよ)。
+.SS 素のシステムコールのインターフェース
+素の \fBclone\fP システムコールは、より \fBfork\fP(2) に近いかたちになっており、
+子プロセスの実行が呼び出しが行われた場所から続けられる。 そのため、 \fBclone\fP() ラッパー関数の引き数 \fIfn\fP と \fIarg\fP
+は省略される。 また、 引き数の順序も違っている。 x86 と他の多くのアーキテクチャにおける、 素のシステムコールのインターフェースは、
+おおまかには次のようになっている。
+.in +4
+.nf
-\fBsys_clone\fP のもう一つの違いは、 \fIchild_stack\fP 引き数がゼロでも良いことである。この場合には、どちらかのプロセスが
+\fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIchild_stack\fP\fB,\fP
+\fB void *\fP\fIptid\fP\fB, void *\fP\fIctid\fP\fB,\fP
+\fB struct pt_regs *\fP\fIregs\fP\fB);\fP
+
+.fi
+.in
+生のシステムコールのもう一つの違いは、 \fIchild_stack\fP 引き数がゼロでも良いことである。この場合には、どちらかのプロセスが
スタックを変更した時に、書き込み時コピー (copy\-on\-write) 方式により
子プロセスがスタック・ページの独立したコピーを得られることが保証される。 この場合、正常に動作させるためには、 \fBCLONE_VM\fP
オプションを指定してはならない。
+いくつかのアーキテクチャでは、システムコールの引き数の順序は上記とは異なっている。 microblaze, ARM, ARM 64, PA\-RISC,
+arc, Power PC, xtensa, MIPS アーキテクチャでは、 4 番目と 5 番目の引き数の順番が逆である。 cris と s390
+アーキテクチャでは、最初と 2 番目の引き数の順番が逆である。
+.SS "blackfin, m68k, sparc"
+blackfin, m68k, sparc では引き数渡しの規約が上記の説明とは異なる。 詳細は、カーネル (と glibc) のソースを参照のこと。
+.SS ia64
+ia64 では、別のインターフェースが使用される:
+.nf
+
+\fBint __clone2(int (*\fP\fIfn\fP\fB)(void *), \fP
+\fB void *\fP\fIchild_stack_base\fP\fB, size_t \fP\fIstack_size\fP\fB,\fP
+\fB int \fP\fIflags\fP\fB, void *\fP\fIarg\fP\fB, ... \fP
+\fB /* pid_t *\fP\fIptid\fP\fB, struct user_desc *\fP\fItls\fP\fB, pid_t *\fP\fIctid\fP\fB */ );\fP
+.fi
+.PP
+上記のプロトタイプは glibc ラッパー関数用のものである。 素のシステムコールのインターフェースには引き数 \fIfn\fP と \fIarg\fP がない。
+また、引き数の順序が変わり、 \fIflags\fP が最初の引き数で、 \fItls\fP が最後の引き数である。
+.PP
+\fB__clone2\fP() は \fBclone\fP() と同じように動作するが、以下の点が異なる: \fIchild_stack_base\fP
+は子プロセスのスタックエリアの最小のアドレスを指し、 \fIstack_size\fP は \fIchild_stack_base\fP
+が指し示すスタックエリアの大きさを示す。
+.SS "Linux 2.4 以前"
Linux 2.4 以前では、 \fBclone\fP() は引き数 \fIptid\fP, \fItls\fP, \fIctid\fP を取らない。
.SH 返り値
.\" gettid(2) returns current->pid;
.SH バージョン
libc5 には \fBclone\fP() はない。glibc2 では \fBclone\fP() が提供されており、このマニュアルページに記載の通りである。
.SH 準拠
-\fBclone\fP() と \fBsys_clone\fP コールは Linux 特有であり、移植を考慮したプログラムでは使用すべき ではない。
+\fBclone\fP() は Linux 特有であり、移植を考慮したプログラムでは使用すべき ではない。
.SH 注意
カーネル 2.4.x 系列では、一般的には \fBCLONE_THREAD\fP フラグを指定しても新しいスレッドの親を
呼び出し元プロセスの親と同じにはしない。 しかし、バージョン 2.4.7〜2.4.18 のカーネルでは、 (カーネル 2.6 と同じように)
CLONE_THREAD と一緒に指定する必要はなくなった。 このフラグはまだ定義されているが、何の効果もない。
i386 上では、 \fBclone\fP() は vsyscall 経由ではなく、直接 \fIint $0x80\fP 経由で呼び出すべきである。
-
-ia64 では、別のシステムコールが使用される:
-.nf
-
-\fBint __clone2(int (*\fP\fIfn\fP\fB)(void *), \fP
-\fB void *\fP\fIchild_stack_base\fP\fB, size_t \fP\fIstack_size\fP\fB,\fP
-\fB int \fP\fIflags\fP\fB, void *\fP\fIarg\fP\fB, ... \fP
-\fB /* pid_t *\fP\fIptid\fP\fB, struct user_desc *\fP\fItls\fP\fB, pid_t *\fP\fIctid\fP\fB */ );\fP
-.fi
-.PP
-\fB__clone2\fP() システムコールは \fBclone\fP() と同じように動作するが、以下の点が異なる:
-\fIchild_stack_base\fP は子プロセスのスタックエリアの最小のアドレスを指し、 \fIstack_size\fP は
-\fIchild_stack_base\fP が指し示すスタックエリアの大きさを示す。
.SH バグ
NPTL スレッド・ライブラリを含んでいる GNU C ライブラリのいくつかのバージョン には、 \fBgetpid\fP(2)
のラッパー関数が含まれており、このラッパー関数は PID をキャッシュする。 このキャッシュ処理が正しく動作するためには glibc の
.\" See also the following bug reports
.\" https://bugzilla.redhat.com/show_bug.cgi?id=417521
.\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910
+.SH 例
+以下のプログラムは、 別の UTS 名前空間で動作する子プロセスを \fBclone\fP() を使って作成する例である。 子プロセスは、自分の UTS
+名前空間においてホスト名を変更する。 それから、親プロセスと子プロセスの両方でシステムのホスト名を表示し、 親プロセスと子プロセスの UTS
+名前空間でホスト名が異なることを確認する。 このプログラムの使用方法については \fBsetns\fP(2) を参照。
+.SS プログラムのソース
+.nf
+#define _GNU_SOURCE
+#include <sys/wait.h>
+#include <sys/utsname.h>
+#include <sched.h>
+#include <string.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+
+#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \e
+ } while (0)
+
+static int /* clone された子プロセスの開始関数 */
+childFunc(void *arg)
+{
+ struct utsname uts;
+
+ /* 子プロセスの UTS 名前空間でホスト名を変更する */
+
+ if (sethostname(arg, strlen(arg)) == \-1)
+ errExit("sethostname");
+
+ /* ホスト名を取得し表示する */
+
+ if (uname(&uts) == \-1)
+ errExit("uname");
+ printf("uts.nodename in child: %s\en", uts.nodename);
+
+ /* sleep を使ってしばらく名前空間をオープンされたままにする。
+ これにより実験を行うことができる \-\- 例えば、
+ 別のプロセスがこの名前空間に参加するなど。 */
+
+ sleep(200);
+
+ return 0; /* 子プロセスを終了する */
+}
+
+#define STACK_SIZE (1024 * 1024) /* clone される子プロセスのスタックサイズ */
+
+int
+main(int argc, char *argv[])
+{
+ char *stack; /* スタックバッファの先頭 */
+ char *stackTop; /* スタックバッファの末尾 */
+ pid_t pid;
+ struct utsname uts;
+
+ if (argc < 2) {
+ fprintf(stderr, "Usage: %s <child\-hostname>\en", argv[0]);
+ exit(EXIT_SUCCESS);
+ }
+
+ /* 子プロセス用のスタックを割り当てる */
+
+ stack = malloc(STACK_SIZE);
+ if (stack == NULL)
+ errExit("malloc");
+ stackTop = stack + STACK_SIZE; /* スタックは下方向に伸びるものとする */
+
+ /* 自分専用の UTS 名前空間を持つ子プロセスを作成する;
+ 子プロセスは childFunc() の実行を開始する */
+
+ pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
+ if (pid == \-1)
+ errExit("clone");
+ printf("clone() returned %ld\en", (long) pid);
+
+ /* 親プロセスの実行はここに来る */
+
+ sleep(1); /* 子プロセスがホスト名を変更する時間を与える */
+
+ /* 親プロセスの UTS 名前空間でのホスト名を表示する;
+ これは子プロセスの UTS 名前空間でのホスト名とは異なる */
+
+ if (uname(&uts) == \-1)
+ errExit("uname");
+ printf("uts.nodename in parent: %s\en", uts.nodename);
+
+ if (waitpid(pid, NULL, 0) == \-1) /* 子プロセスを待つ */
+ errExit("waitpid");
+ printf("child has terminated\en");
+
+ exit(EXIT_SUCCESS);
+}
+.fi
.SH 関連項目
-\fBfork\fP(2), \fBfutex\fP(2), \fBgetpid\fP(2), \fBgettid\fP(2), \fBset_thread_area\fP(2),
-\fBset_tid_address\fP(2), \fBtkill\fP(2), \fBunshare\fP(2), \fBwait\fP(2),
-\fBcapabilities\fP(7), \fBpthreads\fP(7)
+\fBfork\fP(2), \fBfutex\fP(2), \fBgetpid\fP(2), \fBgettid\fP(2), \fBkcmp\fP(2),
+\fBset_thread_area\fP(2), \fBset_tid_address\fP(2), \fBsetns\fP(2), \fBtkill\fP(2),
+\fBunshare\fP(2), \fBwait\fP(2), \fBcapabilities\fP(7), \fBpthreads\fP(7)
.SH この文書について
-この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.40 の一部
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.67 の一部
である。プロジェクトの説明とバグ報告に関する情報は
http://www.kernel.org/doc/man\-pages/ に書かれている。
OSDN Git Service
