.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
-.TH CLONE 2 2013\-01\-01 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) と似た方法で新しいプロセスを作成する。
-\fBfork\fP(2) とは異なり、これらのコールでは、子プロセス (child process) と呼び出し元のプロセスとが、メモリ空間、
-ファイルディスクリプタのテーブル、シグナル・ハンドラのテーブルなどの 実行コンテキストの一部を共有できる。
+このページでは、 glibc の \fBclone\fP() ラッパー関数とその裏で呼ばれるシステムコールの両方について説明している。
+メインの説明はラッパー関数に関するものである。 素のシステムコールにおける差分はこのページの最後の方で説明する。
+
+\fBfork\fP(2) とは異なり、\fBclone\fP() では、子プロセス (child process)
+と呼び出し元のプロセスとが、メモリ空間、ファイルディスクリプタのテーブル、シグナル・ハンドラのテーブルなどの 実行コンテキストの一部を共有できる。
(このマニュアルにおける「呼び出し元のプロセス」は、通常は 「親プロセス」と一致する。但し、後述の \fBCLONE_PARENT\fP の項も参照のこと)
\fBclone\fP() の主要な使用法はスレッド (threads) を実装することである:
一つのプログラムの中の複数のスレッドは共有されたメモリ空間で 同時に実行される。
-When the child process is created with \fBclone\fP(), it executes the function
-\fIfn\fP(\fIarg\fP). (This differs from \fBfork\fP(2), where execution continues in
-the child from the point of the \fBfork\fP(2) call.) The \fIfn\fP argument is a
-pointer to a function that is called by the child process at the beginning
-of its execution. The \fIarg\fP argument is passed to the \fIfn\fP function.
+\fBclone\fP() で子プロセスが作成された時に、作成された子プロセスは関数 \fIfn\fP(\fIarg\fP) を実行する。 (この点が
+\fBfork\fP(2) とは異なる。 \fBfork\fP(2) の場合、子プロセスは \fBfork\fP(2) が呼び出された場所から実行を続ける。)
+\fIfn\fP 引き数は、子プロセスが実行を始める時に子プロセスが呼び出す 関数へのポインタである。 \fIarg\fP 引き数はそのまま \fIfn\fP
+関数へと渡される。
\fIfn\fP(\fIarg\fP) 関数が終了すると、子プロセスは終了する。 \fIfn\fP によって返された整数が子プロセスの終了コードとなる。 子プロセスは、
\fBexit\fP(2) を呼んで明示的に終了することもあるし、致命的なシグナルを受信した 場合に終了することもある。
\fBCLONE_CHILD_SETTID\fP (Linux 2.5.49 以降)
子プロセスのメモリ内の \fIctid\fP が指す場所に子プロセスのスレッド ID を格納する。
.TP
-\fBCLONE_FILES\fP (since Linux 2.0)
+\fBCLONE_FILES\fP (Linux 2.0 以降)
\fBCLONE_FILES\fP が設定された場合、呼び出し元のプロセスと子プロセスはファイルディスクリプタの テーブルを共有する。
呼び出し元プロセスとその子プロセスの一方が作成した ファイルディスクリプタは、もう一方においても有効である。
同じように、一方のプロセスがファイルディスクリプタを閉じたり、 (\fBfcntl\fP(2) \fBF_SETFD\fP 操作を使って)
参照) を参照する)。 これ以降に、呼び出し元のプロセスと子プロセスの一方が ファイルディスクリプタの操作 (ファイルディスクリプタの
オープン・クローズや、ファイルディスクリプタ・フラグの変更) を行っても、もう一方のプロセスには影響を与えない。
.TP
-\fBCLONE_FS\fP (since Linux 2.0)
+\fBCLONE_FS\fP (Linux 2.0 以降)
\fBCLONE_FS\fP が設定された場合、呼び出し元のプロセスと子プロセスが同じファイル・システム
情報を共有する。ファイル・システム情報は、ファイル・システムのルート (root)、 カレント・ワーキング・ディレクトリ (current
working directory) や umask などである。 呼び出し元のプロセスや子プロセスのどちらか一方によって \fBchroot\fP(2),
.\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f
.\" https://lwn.net/Articles/312232/
-An IPC namespace provides an isolated view of System V IPC objects (see
-\fBsvipc\fP(7)) and (since Linux 2.6.30) POSIX message queues (see
-\fBmq_overview\fP(7)). The common characteristic of these IPC mechanisms is
-that IPC objects are identified by mechanisms other than filesystem
-pathnames.
+IPC 名前空間は、独立の System\ V IPC オブジェクト空間 (\fBsvipc\fP(7) 参照) を提供する 。 (Linux 2.6.30
+以降では) 独立した POSIX メッセージキュー空間 (\fBmq_overview\fP(7) 参照) も提供される。 これらの IPC
+機構に共通の特徴として、 IPC オブジェクトはファイルシステムのパス名とは違った仕組みで識別されるという点がある。
-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.
+ある 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) の場合と同様) 呼び出し元のプロセスと同じネットワーク名前空間でプロセスが 作成される。
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_VM\fP が設定されていない場合、子プロセスは \fBclone\fP() が実行された時点での、親プロセスのメモリ空間をコピーした
別のメモリ空間で実行される。 一方のプロセスが行ったメモリへの書き込みや ファイルのマップ/アンマップは、 \fBfork\fP(2)
の場合と同様、もう一方のプロセスには影響しない。
-.SS sys_clone
-The \fBsys_clone\fP system call corresponds more closely to \fBfork\fP(2) in that
-execution in the child continues from the point of the call. As such, the
-\fIfn\fP and \fIarg\fP arguments of the \fBclone\fP() wrapper function are omitted.
-Furthermore, the argument order changes. The raw system call interface is
-roughly:
+.SS 素のシステムコールのインターフェース
+素の \fBclone\fP システムコールは、より \fBfork\fP(2) に近いかたちになっており、
+子プロセスの実行が呼び出しが行われた場所から続けられる。 そのため、 \fBclone\fP() ラッパー関数の引き数 \fIfn\fP と \fIarg\fP
+は省略される。 また、 引き数の順序も違っている。 x86 と他の多くのアーキテクチャにおける、 素のシステムコールのインターフェースは、
+おおまかには次のようになっている。
.in +4
.nf
.fi
.in
-\fBsys_clone\fP のもう一つの違いは、 \fIchild_stack\fP 引き数がゼロでも良いことである。この場合には、どちらかのプロセスが
+生のシステムコールのもう一つの違いは、 \fIchild_stack\fP 引き数がゼロでも良いことである。この場合には、どちらかのプロセスが
スタックを変更した時に、書き込み時コピー (copy\-on\-write) 方式により
子プロセスがスタック・ページの独立したコピーを得られることが保証される。 この場合、正常に動作させるためには、 \fBCLONE_VM\fP
オプションを指定してはならない。
-.SS "Linux 2.4 and earlier"
+
+いくつかのアーキテクチャでは、システムコールの引き数の順序は上記とは異なっている。 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 EXAMPLE
-.SS "Create a child that executes in a separate UTS namespace"
-The following program demonstrates the use of \fBclone\fP() to create a child
-process that executes in a separate UTS namespace. The child changes the
-hostname in its UTS namespace. Both parent and child then display the
-system hostname, making it possible to see that the hostname differs in the
-UTS namespaces of the parent and child. For an example of the use of this
-program, see \fBsetns\fP(2).
-
+.SH 例
+以下のプログラムは、 別の UTS 名前空間で動作する子プロセスを \fBclone\fP() を使って作成する例である。 子プロセスは、自分の UTS
+名前空間においてホスト名を変更する。 それから、親プロセスと子プロセスの両方でシステムのホスト名を表示し、 親プロセスと子プロセスの UTS
+名前空間でホスト名が異なることを確認する。 このプログラムの使用方法については \fBsetns\fP(2) を参照。
+.SS プログラムのソース
.nf
#define _GNU_SOURCE
#include <sys/wait.h>
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE); \e
} while (0)
-static int /* Start function for cloned child */
+static int /* clone された子プロセスの開始関数 */
childFunc(void *arg)
{
struct utsname uts;
- /* Change hostname in UTS namespace of child */
+ /* 子プロセスの UTS 名前空間でホスト名を変更する */
if (sethostname(arg, strlen(arg)) == \-1)
errExit("sethostname");
- /* Retrieve and display hostname */
+ /* ホスト名を取得し表示する */
if (uname(&uts) == \-1)
errExit("uname");
printf("uts.nodename in child: %s\en", uts.nodename);
- /* Keep the namespace open for a while, by sleeping.
- This allows some experimentation\-\-for example, another
- process might join the namespace. */
+ /* sleep を使ってしばらく名前空間をオープンされたままにする。
+ これにより実験を行うことができる \-\- 例えば、
+ 別のプロセスがこの名前空間に参加するなど。 */
sleep(200);
- return 0; /* Child terminates now */
+ return 0; /* 子プロセスを終了する */
}
-#define STACK_SIZE (1024 * 1024) /* Stack size for cloned child */
+#define STACK_SIZE (1024 * 1024) /* clone される子プロセスのスタックサイズ */
int
main(int argc, char *argv[])
{
- char *stack; /* Start of stack buffer */
- char *stackTop; /* End of stack buffer */
+ char *stack; /* スタックバッファの先頭 */
+ char *stackTop; /* スタックバッファの末尾 */
pid_t pid;
struct utsname uts;
exit(EXIT_SUCCESS);
}
- /* Allocate stack for child */
+ /* 子プロセス用のスタックを割り当てる */
stack = malloc(STACK_SIZE);
if (stack == NULL)
errExit("malloc");
- stackTop = stack + STACK_SIZE; /* Assume stack grows downward */
+ stackTop = stack + STACK_SIZE; /* スタックは下方向に伸びるものとする */
- /* Create child that has its own UTS namespace;
- child commences execution in childFunc() */
+ /* 自分専用の UTS 名前空間を持つ子プロセスを作成する;
+ 子プロセスは childFunc() の実行を開始する */
pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]);
if (pid == \-1)
errExit("clone");
printf("clone() returned %ld\en", (long) pid);
- /* Parent falls through to here */
+ /* 親プロセスの実行はここに来る */
- sleep(1); /* Give child time to change its hostname */
+ sleep(1); /* 子プロセスがホスト名を変更する時間を与える */
- /* Display hostname in parent\(aqs UTS namespace. This will be
- different from hostname in child\(aqs UTS namespace. */
+ /* 親プロセスの UTS 名前空間でのホスト名を表示する;
+ これは子プロセスの UTS 名前空間でのホスト名とは異なる */
if (uname(&uts) == \-1)
errExit("uname");
printf("uts.nodename in parent: %s\en", uts.nodename);
- if (waitpid(pid, NULL, 0) == \-1) /* Wait for child */
+ if (waitpid(pid, NULL, 0) == \-1) /* 子プロセスを待つ */
errExit("waitpid");
printf("child has terminated\en");
\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.50 の一部
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.67 の一部
である。プロジェクトの説明とバグ報告に関する情報は
http://www.kernel.org/doc/man\-pages/ に書かれている。
OSDN Git Service
