\fBpreadv\fP(), \fBpwritev\fP(): 非標準だが、最近の BSD にも存在する。
.SH 注意
-POSIX.1\-2001 allows an implementation to place a limit on the number of
-items that can be passed in \fIiov\fP. An implementation can advertise its
-limit by defining \fBIOV_MAX\fP in \fI<limits.h>\fP or at run time via the
-return value from \fIsysconf(_SC_IOV_MAX)\fP. On modern Linux systems, the
-limit is 1024. Back in Linux 2.0 days, this limit was 16.
+POSIX.1\-2001 では、 \fIiov\fP で渡すことができる要素数に上限を設ける実装が認められている。 実装はこの上限値を広告することができ、
+\fI<limits.h>\fP の \fBIOV_MAX\fP を定義することや、 実行時に \fIsysconf(_SC_IOV_MAX)\fP
+の返り値経由で知ることができる。 最近の Linux では、 この上限値は 1024 である。 Linux 2.0 の頃は、 この値は 16 であった。
.\"
\fB unsigned long \fP\fIpos_l\fP\fB, unsigned long \fP\fIpos\fP
これらの引き数は、それぞれ、 \fIoffset\fP の下位 32 ビットと上位 32 ビットである。
-.SS "Historical C library/kernel ABI differences"
-To deal with the fact that \fBIOV_MAX\fP was so low on early versions of Linux,
-the glibc wrapper functions for \fBreadv\fP() and \fBwritev\fP() did some extra
-work if they detected that the underlying kernel system call failed because
-this limit was exceeded. In the case of \fBreadv\fP(), the wrapper function
-allocated a temporary buffer large enough for all of the items specified by
-\fIiov\fP, passed that buffer in a call to \fBread\fP(2), copied data from the
-buffer to the locations specified by the \fIiov_base\fP fields of the elements
-of \fIiov\fP, and then freed the buffer. The wrapper function for \fBwritev\fP()
-performed the analogous task using a temporary buffer and a call to
-\fBwrite\fP(2).
+.SS "以前の C ライブラリとカーネル ABI の違い"
+古いバージョンの Linux では \fBIOV_MAX\fP が非常に小さかったという事実に対処するため、 glibc の \fBreadv\fP() と
+\fBwritev\fP() のラッパー関数は、 その関数の内部で呼ばれるカーネルシステムコールがこの上限を超過して失敗したことを検出すると、
+追加の動作をしていた。 \fBreadv\fP() の場合、 ラッパー関数は \fIiov\fP
+で指定された全ての要素を格納できる大きさの一時バッファーを割り当て、 \fBread\fP(2) を呼び出す際にそのバッファーを渡し、
+そのバッファーのデータを \fIiov\fP の各要素の \fIiov_base\fP フィールドが指定する場所にコピーしてから、 そのバッファーを解放していた。
+\fBwritev\fP() のラッパー関数も、 同じように一時バッファーを使って \fBwrite\fP(2) を呼び出していた。
-The need for this extra effort in the glibc wrapper functions went away with
-Linux 2.2 and later. However, glibc continued to provide this behavior
-until version 2.10. Starting with glibc version 2.9, the wrapper functions
-provide this behavior only if the library detects that the system is running
-a Linux kernel older than version 2.6.18 (an arbitrarily selected kernel
-version). And since glibc 2.20 (which requires a minimum Linux kernel
-version of 2.6.32), the glibc wrapper functions always just directly invoke
-the system calls.
+glibc ラッパー関数でのこの追加の動作は Linux 2.2 以降では必要なくなった。 しかし、 glibc はバージョン 2.10
+まではこの動作を続けていた。 glibc 2.9 以降では、 システムがバージョン 2.6.18 より前の Linux カーネル (2.6.18
+は勝手に選択したカーネルバージョンである) を実行しているとライブラリが検出した場合にのみ、 ラッパー関数はこの動作を行う。 glibc 2.20
+以降では、 (Linux カーネルのバージョン 2.6.32 以降が必須条件となり) glibc
+のラッパー関数は常にシステムコールを直接呼び出すようになっている。
.SH バグ
ファイルディスクリプタに対する操作を行う \fBreadv\fP() や \fBwritev\fP() と、
標準入出力ライブラリの関数をごちゃまぜにして呼ぶのはお薦めしない。
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2015-01-23 22:23+0900\n"
-"PO-Revision-Date: 2015-01-23 22:43+0900\n"
+"PO-Revision-Date: 2015-01-24 03:47+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"limit by defining B<IOV_MAX> in I<E<lt>limits.hE<gt>> or at run time via the "
"return value from I<sysconf(_SC_IOV_MAX)>. On modern Linux systems, the "
"limit is 1024. Back in Linux 2.0 days, this limit was 16."
-msgstr ""
+msgstr "POSIX.1-2001 では、 I<iov> で渡すことができる要素数に上限を設ける実装が認められている。 実装はこの上限値を広告することができ、 I<E<lt>limits.hE<gt>> の B<IOV_MAX> を定義することや、 実行時に I<sysconf(_SC_IOV_MAX)> の返り値経由で知ることができる。 最近の Linux では、 この上限値は 1024 である。 Linux 2.0 の頃は、 この値は 16 であった。"
#. type: SS
#: build/C/man2/readv.2:242
#. type: SS
#: build/C/man2/readv.2:257
-#, fuzzy, no-wrap
-#| msgid "C library/kernel ABI differences"
+#, no-wrap
msgid "Historical C library/kernel ABI differences"
-msgstr "C ライブラリとカーネル ABI の違い"
+msgstr "以前の C ライブラリとカーネル ABI の違い"
#. type: Plain text
#: build/C/man2/readv.2:283
-#, fuzzy
-#| msgid ""
-#| "POSIX.1-2001 allows an implementation to place a limit on the number of "
-#| "items that can be passed in I<iov>. An implementation can advertise its "
-#| "limit by defining B<IOV_MAX> in I<E<lt>limits.hE<gt>> or at run time via "
-#| "the return value from I<sysconf(_SC_IOV_MAX)>. On Linux, the limit "
-#| "advertised by these mechanisms is 1024, which is the true kernel limit. "
-#| "However, the glibc wrapper functions do some extra work if they detect "
-#| "that the underlying kernel system call failed because this limit was "
-#| "exceeded. In the case of B<readv>(), the wrapper function allocates a "
-#| "temporary buffer large enough for all of the items specified by I<iov>, "
-#| "passes that buffer in a call to B<read>(2), copies data from the buffer "
-#| "to the locations specified by the I<iov_base> fields of the elements of "
-#| "I<iov>, and then frees the buffer. The wrapper function for B<writev>() "
-#| "performs the analogous task using a temporary buffer and a call to "
-#| "B<write>(2)."
msgid ""
"To deal with the fact that B<IOV_MAX> was so low on early versions of Linux, "
"the glibc wrapper functions for B<readv>() and B<writev>() did some extra "
"of I<iov>, and then freed the buffer. The wrapper function for B<writev>() "
"performed the analogous task using a temporary buffer and a call to "
"B<write>(2)."
-msgstr ""
-"POSIX.1-2001 では、 I<iov> で渡すことができる要素数に上限を設ける実装が認めら"
-"れている。 実装は、 I<E<lt>limits.hE<gt>> の B<IOV_MAX> を定義することや、実"
-"行時に I<sysconf(_SC_IOV_MAX)> の返り値経由で、この上限を広告することができ"
-"る。 Linux では、この仕組みにより広告される上限は 1024 であり、 この値はカー"
-"ネルでの上限そのものである。 一方で、glibc のラッパー関数は、その関数の内部で"
-"呼ばれるカーネル システムコールがこの上限を超過して失敗したことを検出する"
-"と、 追加の動作をする。 B<readv>() の場合、ラッパー関数は I<iov> で指定され"
-"た全ての要素を格納できる大きさの一時バッファを割り当て、 B<read>(2) を呼び出"
-"す際にそのバッファを渡し、 そのバッファのデータを I<iov> の各要素の "
-"I<iov_base> フィールドが指定する場所にコピーしてから、 そのバッファを解放す"
-"る。 B<writev>() のラッパー関数も、同じように一時バッファを使って "
-"B<write>(2) を呼び出す。"
+msgstr "古いバージョンの Linux では B<IOV_MAX> が非常に小さかったという事実に対処するため、 glibc の B<readv>() と B<writev>() のラッパー関数は、 その関数の内部で呼ばれるカーネルシステムコールがこの上限を超過して失敗したことを検出すると、 追加の動作をしていた。 B<readv>() の場合、 ラッパー関数は I<iov> で指定された全ての要素を格納できる大きさの一時バッファーを割り当て、 B<read>(2) を呼び出す際にそのバッファーを渡し、 そのバッファーのデータを I<iov> の各要素の I<iov_base> フィールドが指定する場所にコピーしてから、 そのバッファーを解放していた。 B<writev>() のラッパー関数も、 同じように一時バッファーを使って B<write>(2) を呼び出していた。"
#. type: Plain text
#: build/C/man2/readv.2:294
"version). And since glibc 2.20 (which requires a minimum Linux kernel "
"version of 2.6.32), the glibc wrapper functions always just directly invoke "
"the system calls."
-msgstr ""
+msgstr "glibc ラッパー関数でのこの追加の動作は Linux 2.2 以降では必要なくなった。 しかし、 glibc はバージョン 2.10 まではこの動作を続けていた。 glibc 2.9 以降では、 システムがバージョン 2.6.18 より前の Linux カーネル (2.6.18 は勝手に選択したカーネルバージョンである) を実行しているとライブラリが検出した場合にのみ、 ラッパー関数はこの動作を行う。 glibc 2.20 以降では、 (Linux カーネルのバージョン 2.6.32 以降が必須条件となり) glibc のラッパー関数は常にシステムコールを直接呼び出すようになっている。"
#. type: Plain text
#: build/C/man2/readv.2:301
# pagename,#complete,#remaining,#all
fopencookie.3,65,33,98
open_by_handle_at.2,128,16,144
-readv.2,56,4,60
symlink.7,63,8,71
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>stdio</B></TD></TR>
<TR><TD>fopencookie.3</TD><TD>33/98</TD><TD>66.33</TD></TR>
<TR class="over80"><TD>open_by_handle_at.2</TD><TD>16/144</TD><TD>88.89</TD></TR>
-<TR class="over80"><TD>readv.2</TD><TD>4/60</TD><TD>93.33</TD></TR>
<TR class="over80"><TD>symlink.7</TD><TD>8/71</TD><TD>88.73</TD></TR>
<TR><TD ALIGN="center" COLSPAN=3 BGCOLOR="Yellow"><B>stdlib</B></TD></TR>
<TR><TD>getauxval.3</TD><TD>34/86</TD><TD>60.47</TD></TR>
<TR><TD>vdso.7</TD><TD>139/184</TD><TD>24.46</TD></TR>
-<TR><TD COLSPAN=3>Total 49 pages</TD></TR>
+<TR><TD COLSPAN=3>Total 48 pages</TD></TR>
</TABLE>
</BODY></HTML>
OSDN Git Service
