<?xml version='1.0' encoding='EUC-JP'?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
  "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" >

<!--
Document type declaration was this:
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN"[]>
when this was a sgml document.
-->

<book id="index">
 <bookinfo>
  <title>The Linux 2.4 SCSI subsystem HOWTO</title>

  <authorgroup>
   <author>
    <firstname>Douglas</firstname>
    <surname>Gilbert</surname>
    <affiliation>
     <address>
      <email>dgilbert@interlog.com</email>
     </address>
    </affiliation>
   </author>
   <othercredit role="translator" lang="ja">
    <surname>高橋</surname><firstname>聡</firstname>
    <contrib>日本語訳</contrib>
	  <affiliation>
	   <address><email>hisai@din.or.jp</email></address>
	  </affiliation>
   </othercredit>
  </authorgroup>
  <pubdate>2003-05-04</pubdate>

  <revhistory>
     <revision>
       <revnumber>2.0</revnumber>
       <date>2003-05-04</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
       <!--
       lk2.4.20, linuxdoc->tldp, sATA and SAS, last sector on raw devs,
       blockdev
       -->
       カーネル 2.4.20対応。linuxdoc から　tldp に移行。raw デバイスの
       最終セクタについて。blockdev について。
       </revremark>
     </revision>
     <revision>
       <revnumber>1.9</revnumber>
       <date>2002-11-20</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
         <!--
         convert to xml, lk2.4.19, spelling
         -->
         xml に変換。カーネル 2.4.19 対応。スペル修正。
       </revremark>
     </revision>
     <revision>
       <revnumber>1.8</revnumber>
       <date>2002-05-05</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
         <!--
         scsihosts comma delimiter, grub+lilo
         -->
         scsihosts の区切り文字にカンマ。grub と lilo について。
       </revremark>
     </revision>
     <!-- Additional (*earlier*) revision histories go here -->
     <revision>
       <revnumber>1.7</revnumber>
       <date>2002-04-27</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
            <!--
      mkinitrd, scsi_debug, 2.4.18, more ATAPI
      -->
      mkinitrd と scsi_debug について。カーネル 2.4.18 対応。ATAPI を詳細に。
       </revremark>
     </revision>
     <revision>
       <revnumber>1.6</revnumber>
       <date>2002-01-26</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
       <!--
             ATAPI cdrom selection
       -->
       ATAPI の CD-ROM セクション。
       </revremark>
     </revision>
     <revision>
       <revnumber>1.5</revnumber>
       <date>2001-12-21</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
         <!--
         16 byte SCSI commands, SCSI_IOCTL_GET_PCI
         -->
         16 バイトの SCSI コマンド。SCSI_IOCTL_GET_PCI。
       </revremark>
     </revision>
     <revision>
       <revnumber>1.4</revnumber>
       <date>2001-08-26</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
  <!--
  spelling, dd_rescue, mkinitrd example, lk 2.4 changes, 1394.
  -->
  スペル修正。dd_rescue。mkinitrd の例。カーネル 2.4 対応。1394。
       </revremark>
     </revision>
     <revision>
       <revnumber>1.3</revnumber>
       <date>2001-08-26</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
  <!--
  ATAPI CDROM section, alter title, U320, iSCSI.
  -->
        ATAPI の CD-ROM のセクション。タイトル変更。U320 と iSCSI。
       </revremark>
     </revision>
     <revision>
       <revnumber>1.2</revnumber>
       <date>2001-03-25</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
        <!--
       Information about scu, dt, "Alt" sequences, more notes.
        -->
       scu と dt についての情報。「Alt」シーケンス。注釈増やす。
       </revremark>
     </revision>
     <revision>
       <revnumber>1.1</revnumber>
       <date>2001-01-22</date>
       <authorinitials>dpg</authorinitials>
       <revremark>
       <!--
       Add osst description, _EXTRA_DEVS limitations.
       -->
       osst について解説。_EXTRA_DEVS の制限。
       </revremark>
     </revision>
  </revhistory>

  <copyright>
   <year>2001</year>
   <year>2002</year>
   <year>2003</year>
   <holder>Douglas Gilbert</holder>
  </copyright>

  <legalnotice>
   <para>
      Permission is granted to copy, distribute and/or modify this document
      under the terms of the GNU Free Documentation License, Version 1.1
      or any later version published by the Free Software Foundation;
      with no Invariant Sections, with no Front-Cover Texts, and with
      no Back-Cover Texts.
   </para>
   <para>
    For an online copy of the license see
    <ulink url="http://www.fsf.org/copyleft/fdl.html">
    <literal>www.fsf.org/copyleft/fdl.html</literal></ulink>.
   </para>
   <para>
  	【訳註：GNU Free Documentation License, Version 1.1 については、
    <ulink url="http://www.opensource.jp/fdl/fdl.ja.html">
  	GNU フリー文書利用許諾契約書</ulink> 
  	を参考にしてください】
   </para>

  </legalnotice>

  <abstract>
  <para>
    <!--
    This document describes the SCSI subsystem as the Linux kernel
    enters the 2.4 production series.
    An external view of the SCSI subsystem is the main theme.
    Material is included to help the system administration of the
    Linux SCSI subsystem. There are also brief descriptions of
    ioctl()s and interfaces that may be relevant to those writing
    applications that use this subsystem.
    -->
    このドキュメントは、Linux カーネルが 2.4 系になった時点での SCSI 
    サブシステムを解説します。
    SCSI サブシステムを概観していくのが主な目的です。
    Linux の SCSI サブシステムをシステム管理していくのに役立つ資料が掲載
    してあります。またサブシステムを利用するアプリケーションを書く人に参考
    となるよう、ioctl() やインターフェースについても簡単に説明します。
  </para>
  </abstract>
 </bookinfo>

<toc></toc>

  <chapter id="intro">
  		<!--
      <title>Introduction</title>
  		-->
      <title>はじめに</title>
<para>
<!--
This document describes the SCSI subsystem as the Linux kernel
enters the 2.4 production series. 
-->
このドキュメントは、Linux カーネルが 2.4 系になった時点での SCSI 
サブシステムを解説します。
</para>
<para>
<!--
An external view of the SCSI subsystem is the main theme.
Material is included to help the system administration of the Linux SCSI
subsystem. There are also brief descriptions of ioctl()s and interfaces
that may be relevant to those writing applications that use this subsystem.
However internal data structures and design issues are not addressed
[see reference <link linkend="W2">W2</link>]. To unclutter the presentation,
compile options and system calls (including ioctl()s) have been placed in
<xref linkend="compileopt"/>. Although not strictly part of the SCSI 
subsystem, there is also a description of raw devices in 
<xref linkend="rawdev"/>.
-->
SCSI サブシステムを概観していくのが主な目的です。
Linux の SCSI サブシステムのシステム管理に役立つ資料が含まれています。
また、サブシステムを利用するアプリケーションを書く人向けに、ioctl()の
インターフェースにも触れています。
しかし、内部のデータ構造とその設計上の問題は扱っていません(<link 
linkend="W2">W2</link>を参照)。説明が混乱しないように、コンパイルオプション
とシステムコール(ioctl()を含む)は、<xref linkend="compileopt"/>
に記述します。raw デバイスは厳密には SCSI サブシステムの一部ではありませんが、
これについての説明も<xref linkend="rawdev"/>にあります。
</para>
<para>
<!--
For those who have no interest in the SCSI subsystem and just want to get
their ATAPI cd writer going, see <xref linkend="sratapi"/>.
It may also be useful to browse <xref linkend="arch"/>.
-->
SCSI サブシステムに興味がない方や ATAPI CD ライターを動作させたいだけなら、
<xref linkend="sratapi"/>を見てください。
<xref linkend="arch"/>に目を通すのも役に立つかもしれません。
</para>
<para>
<!--
This document follows on from one written five years ago by Drew
Eckhardt called the SCSI-HOWTO [see reference <link linkend="W7">W7</link>].
That document described the SCSI subsystem in Linux kernel 1.2 and 1.3
series. It is still available from the Linux Documentation Project
[LDP, see reference <link linkend="W8">W8</link>] in its "unmaintained"
section. Both documents have roughly similar structures although Drew's
document has a lot of information on the adapter drivers.
-->
このドキュメントは、5 年前に Drew Eckhardt 氏が書いた SCSI-HOWTO 
(<link linkend="W7">W7</link>を参照)を引き継いだものです。
SCSI-HOWTO では、Linux カーネルの 1.2 と 1.3 系の SCSI サブシステム
を説明しています。Linux Documentation Project(LDP。<link linkend="W8">W8
</link>を参照)からまだ得られますが、「更新なし(unmaintained)」セクションに
置かれています。この文書も SCSI-HOWTO も似たような構成になっていますが、Drew 
氏のドキュメントにはアダプタやドライバについてたくさんの情報が記述してあり
ます。
</para>
<para>
【訳註：Drew Eckhardt 氏が書いた SCSI-HOWTO の日本語訳は、
<ulink url="http://www.linux.or.jp/JF/JFdocs/archive/SCSI-HOWTO.html">
SCSI-HOWTO の日本語訳</ulink>を参照してください】
</para>
<para>
<!--
This document can be found in electronic form at
<ulink url="http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO">
<literal>www.tldp.org/HOWTO/SCSI-2.4-HOWTO</literal></ulink>.
The home site and perhaps the most up to date version of this
document can be found at
<ulink url="http://www.torque.net/scsi/SCSI-2.4-HOWTO">
<literal>www.torque.net/scsi/SCSI-2.4-HOWTO</literal></ulink> (this is
the multi-page html version).
At that location this document is rendered in txt, ps, pdf, a single 
(long) page of html as well as multi-page html (e.g. the postscript
version is at <ulink url="http://www.torque.net/scsi/SCSI-2.4-HOWTO.ps">
<literal>www.torque.net/scsi/SCSI-2.4-HOWTO.ps</literal></ulink>).
-->
このドキュメントは電子形式で<ulink 
url="http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO">
<literal>www.tldp.org/HOWTO/SCSI-2.4-HOWTO</literal></ulink>にあります。
ホームサイト(およびおそらくこのドキュメントの最新版が見られるところ)は、
<ulink url="http://www.torque.net/scsi/SCSI-2.4-HOWTO">
<literal>www.torque.net/scsi/SCSI-2.4-HOWTO</literal></ulink>です(これは
マルチページ html 形式)。
このサイトでは、ドキュメントが txt や ps、pdf、マルチページ html とシングル
ページ html(長い)などの形式があります(例えば postscript 版は
<ulink url="http://www.torque.net/scsi/SCSI-2.4-HOWTO.ps">
<literal>www.torque.net/scsi/SCSI-2.4-HOWTO.ps</literal></ulink>)
です。
</para>
<para>
<!--
This document was last altered on 4th May 2003.
-->
このドキュメントを最後に更新したのは、2003 年 5 月 4 日です。
</para>
</chapter>

<chapter id="arch">
      <!--
  		<title>Architectural Overview</title>
  		-->
  		<title>構成を概観する</title>
<para>
<!--
The SCSI subsystem has a 3 level architecture with the "upper" level
being closest to the user/kernel interface while the "lower" level
is closest to the hardware. The upper level drivers are commonly known
by a terse two letter abbreviation (e.g. "sd" for SCSI disk driver).
The names of the corresponding module drivers which, for historical
reasons, sometimes differ from the built in driver names are shown in
braces in the following diagram.
-->
SCSI サブシステムは 3 レイヤから構成されていて、「高」レベルはユーザー空間
やカーネル空間のインタフェースに、「低」レベルはハードウェアに接しています。
高レベルのドライバは、一般に 2 文字の短い略語で知られています(例えば
「sd」は SCSI ディスクドライバ)。
対応するモジュールドライバの名称は下記の図表の{}内を見てください。
歴史的な理由により、モジュールドライバの名称と組み込みドライバの名称が
異なる場合があります。
</para>

    <mediaobject>
      <imageobject>
        <imagedata fileref="scsi-arch.eps" format="EPS"/>
      </imageobject>
      <imageobject>
        <imagedata fileref="scsi-arch.jpg" format="JPG"/>
      </imageobject>
      <caption><para>
      <!--
  		The 3 level driver architecture of the SCSI subsystem.
  		-->
  		SCSI サブシステムの 3 レベルのドライバ構造
      </para></caption>
    </mediaobject>

<para>
<!--
The upper level supports the user-kernel interface. In the case of sd and sr
this is a block device interface while for st and sg this is a character
device interface. Any operation using the SCSI subsystem (e.g. reading a
sector from a disk) involves one driver at each of the 3 levels (e.g. sd,
SCSI mid level and aic7xxx drivers).
-->
高レベルのサブシステムは、ユーザとカーネルの界面をサポートしています。
sd と sr はブロックデバイス、st と sg はキャラクタ・デバイスの
インタフェースです。
SCSI サブシステムを使ったどんな操作(例えばディスクからセクタを読み出す)
も、3 レイヤのドライバをそれぞれ 1 つずつ使います(例えば sd と SCSI の
中間レベルのドライバ、aic7xxx ドライバ)。
</para>
<para>
<!--
As can be seen from the diagram, the SCSI mid level is common to all
operations. The SCSI mid level defines internal interfaces and provides
common services to the upper and lower level drivers. Ioctls provided by
the mid level are available to the file descriptors belonging to any of
the 4 upper level drivers.
-->
図を見てわかるように、SCSI の中間レベルはすべての操作で共通です。
SCSI の中間レベルは、内部インタフェースを定義しており、高レベル、低レベルの
ドライバに共通のサービスを提供します。中間レベルが提供する ioctl は、ファイル
ディスクリプタが高レベルの 4 つのドライバのどれに属していても有効です。
</para>
<para>
<!--
The most common operation on a block device is to "mount" a
file system. For a sd device typically a partition is mounted
(e.g. <command>mount -t ext2 /dev/sda6 /home</command>). For a
sr device usually the whole device is mounted (e.g. <command>
mount -t iso9660 /dev/sr0 /mnt/cdrom</command>). The <command>dd
</command> command can be used to read or write from block devices.
In this case the block size argument ("bs") needs to be set to
the block size of the device (e.g. 512 bytes for most disks)
or an integral multiple of that device block size (e.g. 8192 bytes).
A recent addition to the block subsystem allows a device (or partition)
to be mounted more than once, at different mount points.
-->
ブロックデバイスに対して最もよく行われる操作は、ファイルシステム
の「マウント」です。通常 sd デバイスがあるパーティションをマウントしたり
(例 <command>mount -t ext2 /dev/sda6 /home</command>)、sr デバイスがデバイス
全体をマウントしたりします
(例 <command> mount -t iso9660 /dev/sr0 /mnt/cdrom</command>)。
ブロックデバイスからの読み書きには <command>dd</command> コマンドが使えます。
この場合は、ブロックの大きさを表す引数(「bs」)として、そのデバイスのブロック
の大きさ(例えばディスクの場合はたいてい 512 バイト)を設定するか、そのブロック
の大きさの整数倍(例えば 8192 バイト)を設定する必要があります。
最近ブロックデバイスサブシステムは、1 つのデバイス(もしくはパーティション)
を何回にも渡って、多重マウントできるようになりました。
</para>
<para>
<!--
Sd is a member of the generic disk family, as is the hd device from the
IDE subsystem. Apart from mounting sd devices, the <command>fdisk
</command> command is available to view or modify a disk's
partition table. Although the <command>hdparm</command> command is
primarily intended for ATA disks (also known as IDE or EIDE disks), some
options work on SCSI disks.
-->
sd は汎用ディスクの 1 つで、IDE サブシステムの hd に相当します。
sd デバイスをマウントから外せば、<command>fdisk</command> コマンドを
使ってディスクのパーティションテーブルを見たり、修正したりできます。
<command>hdparm</command> は、もともと ATA ディスク(IDE や EIDE ディスク
として知られている)を扱うコマンドですが、SCSI ディスクに対して機能する
オプションもあります。
</para>
<para>
<!--
Sr is a member of the CD-ROM subsystem. Apart from mounting file
systems (e.g. iso9660), audio CDs can also be read. The latter
action does <emphasis>not</emphasis> involve mounting a file
system but typically by invoking some ioctls. General
purpose Linux commands such as <command>dd</command> cannot be
used on audio CDs.
-->
sr は CD-ROM サブシステムの 1 つです。ファイルシステム(例えば iso9660)
をマウントできるほか、オーディオ CD を読むこともできます。オーディオ CD 
を読む際は、ファイルシステムをマウント<emphasis>しません</emphasis>が、普通は 
ioctl が何回か実行されます。<command>dd</command> のような一般的な Linux 
コマンドは、オーディオ CD には使えません。
</para>
<para>
<!--
St is a char device for reading and writing tapes. Typically the 
<command>mt</command> command is used to perform data transfers and
other control functions.
-->
st はキャラクタデバイスで、テープを読み書きします。データの転送やその他の
制御には、通常 <command>mt</command> コマンドを使います。
</para>
<para>
<!--
Sg is a SCSI command pass through device that uses a char device
interface. General purpose Linux commands should <emphasis>not
</emphasis> be used on sg devices. Applications such
as SANE (for scanners), <command>cdrecord</command> and 
<command>cdrdao</command> (for cd writers) and
<command>cdparanoia</command> (for reading audio CDs digitally) use sg.
-->
sg はキャラクタデバイスのインタフェースを使うデバイスに SCSI コマンド
をそのまま渡します。汎用的な Linux コマンドでは、sg デバイスを<emphasis>
使わない方が良いでしょう</emphasis>。sg を利用している
アプリケーションは、SANE(スキャナー)や <command>cdrecord</command>、
<command>cdrdao</command> (CD ライター)、<command>cdparanoia</command> 
(オーディオ CD をデジタルに読み込む)などです。
</para>
</chapter>

<chapter id="names">
      <!--
  		<title>Names and Addresses</title>
  		-->
  		<title>名前とアドレス</title>
<para>
<!--
This section covers the various naming schemes that exist in Linux
and the SCSI worlds and how they interact.
-->
このセクションでは、Linux と SCSI の分野で使われている呼称と、それぞれの
関係を説明します。
</para>

<sect1 id="scsiaddr">
<!--
      <title>SCSI Addressing</title>
-->
      <title>SCSI のアドレスの付け方</title>
<para>
<!--
Linux has a four level hierarchical addressing scheme for SCSI devices:
-->
Linux では、SCSI デバイスに対して、4 レイヤの階層的なアドレス付けをして
います。
<itemizedlist>
<!--
<listitem><para>SCSI adapter number [host]</para></listitem>
<listitem><para>channel number [bus]</para></listitem>
<listitem><para>id number [target]</para></listitem>
<listitem><para>lun [lun]</para></listitem>
-->
<listitem><para>SCSI アダプタ番号 [host]</para></listitem>
<listitem><para>チャネル番号 [bus]</para></listitem>
<listitem><para>ID 番号 [target]</para></listitem>
<listitem><para>LUN [lun]</para></listitem>
</itemizedlist>
</para>
<para>
<!--
"Lun" is the common SCSI abbreviation of Logical Unit Number. The terms
in brackets are the name conventions used by device pseudo file system
(devfs). "Bus" is used in preference to "channel" in the description below.
-->
「LUN」は、SCSI の Logical Unit Number の略称です。［］の中の単語は、
擬似デバイスファイルシステム(devfs)が便宜上使用する名前です。以降の説明
では、「チャネル」よりも「バス」を主に用います。
</para>
<para>
<!--
The SCSI adapter number is typically an arbitrary numbering of the adapter
cards on the internal IO buses (e.g. PCI, PCMCIA, ISA etc) of the computer.
Such adapters are sometimes termed as HBAs (host bus adapters).
SCSI adapter numbers are issued by the kernel in ascending order starting 
with 0.
-->
SCSI アダプタ番号は、通常はコンピュータの内部入出力バス(PCI、PCMCIA、ISA など)
にあるアダプタカードに対して、ある並びで付けられた番号です。
このようなアダプタを HBA(host bus adapter)と言う場合もあります。
SCSI アダプタの番号は、カーネルが 0 から昇順に発行します。
</para>
<para>
<!--
Each HBA may control one or more SCSI buses. The various types of SCSI
buses are listed in <xref linkend="scsibus"/>.
-->
HBA はそれぞれ、SCSI バスを 1 つ以上制御します。様々なタイプの SCSI バス
を<xref linkend="scsibus"/>に挙げています。
</para>
<para>
<!--
Each SCSI bus can have multiple SCSI devices connected to it. In SCSI
parlance the HBA is called the "initiator" and takes up one SCSI id
number (typically 7). The initiator
-->
SCSI バスにはそれぞれ複数の SCSI デバイスが接続できます。SCSI 用語では 
HBA を「イニシエータ」と呼び、HBA は SCSI ID 番号(通常は 7)を 1 つ
<footnote><para>
<!--
SCSI standards allow for multiple initiators to be present on a single bus.
This is not well supported in Linux although there are patches around
that improve this situation.
-->
SCSI 規格では、1 本のバス上に複数のイニシエータがあってもかまいません。
Linux ではうまくいきませんが、状況を改善するパッチがあります。
</para></footnote>
<!--
talks to targets which are commonly
known as SCSI devices (e.g. disks). On SCSI parallel buses the number
of ids is related to the width. 8 bit buses (sometimes called "narrow")
can have 8 SCSI ids of which 1 is taken by the HBA leaving 7 for SCSI
devices. Wide SCSI buses are 16 bits wide and can have a maximum of 15
SCSI devices (targets) attached. The SCSI 3 draft standard allows a
large number of ids to be present on a SCSI bus.
-->
取ります。イニシエータは SCSI デバイスと呼ばれるターゲット(例えばディスク)
とやり取りします。
SCSI のパラレルバスでは、ID の数は SCSI の幅と関連があります。
8 ビットのバス(「narrow」と呼ぶことがあります)は、8 つの SCSI ID を持ち、
その内 1 つは HBA に、残りの 7 つは SCSI デバイスになります。wide SCSI 
バスは 16 ビット幅で、最大で 15 個 の SCSI デバイス(ターゲット)を接続できます。
SCSI 3 規格のドラフトでは、もっとたくさんの ID を SCSI バス上に置けます。
</para>
<para>
<!--
Each SCSI device can contain multiple Logical Unit Numbers (LUNs). These
are typically used by sophisticated tape and cdrom units that support
multiple media.
-->
各 SCSI デバイスは、複数の Logical Unit Number (LUN)を保持できます。
このような複数の LUN は、複数個の媒体をサポートしている、高級なテープ装置や 
CD-ROM 装置で使います。
</para>
<para>
<!--
So Linux's flavour of SCSI addressing is a four level hierarchy:
-->
というわけで、Linux における SCSI のアドレス付けの特徴は、4 レイヤの階層と
なります。
<programlisting>
&lt;scsi(_adapter_number), channel, id, lun>
</programlisting>
<!--
Using the naming conventions of devfs this becomes:
-->
devfs の名前の付け方に習うと、これは下記のようになります。
<programlisting>
&lt;host, bus, target, lun>
</programlisting>
</para>
</sect1>

<sect1 id="dnames">
      <!--
  		<title>Device Names</title>
  		-->
  		<title>デバイス名</title>
<para>
<!--
A device name can be thought of as a gateway to a kernel driver that
controls a device rather than the device itself. Hence there can be
multiple device names some of which may offer slightly different
characteristics, all mapping to the same actual device.
-->
デバイス名は、デバイスそのものというより、それを制御するカーネルドライバ
への入口と考えられます。したがって、複数のデバイス名が同一のデバイスを指す時
もあり、その場合は少々異なる特性を提供するものが混ざることになるでしょう。
</para>
<para>
<!--
The device names of the various SCSI devices are found within the
<filename>/dev</filename> directory. Traditionally in Linux, SCSI
devices have been identified by their major and minor device number
rather than their SCSI bus addresses (e.g. SCSI target id and LUN).
The device pseudo file system (devfs) moves away from the major and
minor device number scheme and for the SCSI subsystem uses device names
based on the SCSI bus addresses [discussed later in
<xref linkend="dnamesdevfs"/> and see reference: <link linkend="W5">W5</link>].
Alternatively, there is a utility called <command>scsidev</command>
which addresses this issue within the scope of the Linux SCSI subsystem
and thus does not have the same system wide impact as devfs. Scsidev is
discussed later in <xref linkend="dnamesscsidev"/> and ref: 
<link linkend="W6">W6</link>. 
-->
<filename>/dev</filename> ディレクトリには、さまざまな SCSI デバイス名が
あります。これまで Linux では、SCSI デバイスを識別するのに SCSI のバス・
アドレス(例えば SCSI のターゲット ID や LUN)ではなく、そのメジャー、マイナー
番号を使ってきました。
擬似デバイスファイルシステム(devfs)は、そのメジャー、マイナー番号を
使った方式から、SCSI のバス・アドレスに基づいたデバイス名を使う方式
に移行しました(後ほど<xref linkend="dnamesdevfs"/>で議論します。<link 
linkend="W5">W5</link>も参照)。
別の方法として、<command>scsidev</command> というユーティリティがあります。この
ユーティリティでは、変更点を Linux の SCSI サブシステムの内部で扱いますので、
devfs のようにシステム全体に影響を及ぼしません。
scsidev は後に<xref linkend="dnamesscsidev"/>で議論します。
<link linkend="W6">W6</link>も参照してください。
</para>
<para>
<!--
Eight block major numbers are reserved for SCSI disks: 8, 65, 66, 67, 68,
69, 70 and 71. Each major can accommodate 256 minor numbers which, in the
case of SCSI disks, are subdivided as follows:
-->
SCSI ディスクにはブロックメジャー番号が 8 つ割り当てられています。8、65、
66、67、68、69、70、71 がその番号です。メジャー番号はそれぞれ 256 のマイナー
番号を保有でき、SCSI ディスクの場合は下記のように分割されます。
<programlisting>
[b,8,0]    /dev/sda
[b,8,1]    /dev/sda1
....
[b,8,15]   /dev/sda15
[b,8,16]   /dev/sdb
[b,8,17]   /dev/sdb1
....
[b,8,255]  /dev/sdp15
</programlisting>
</para>
<para>
<!--
The disk device names without a trailing digit refer to the whole disk
(e.g. <filename>/dev/sda</filename>)
while those with a trailing digit refer to one of the 15 allowable
partitions 
-->
数字が後ろに付かないディスクデバイス名(例えば <filename>/dev/sda</filename>)
は、ディスク全体を指しています。
これに対して数字が後ろに付いているディスクは、そのディスク内のパーティション
(15 個まで認められている)
<footnote><para>
<!--
If 15 partitions is too limiting then the Logical Volume Manager (LVM)
might be considered. See <filename>/usr/src/linux/Documentation/LVM-HOWTO
</filename>. LVM will also allow a logical partition to span multiple
block devices.
-->
15 個のパーティションで足りなければ、Logical Volume Manager (LVM)を検討
してください。<filename>/usr/src/linux/Documentation/LVM-HOWTO</filename>
を参照してください。LVM は、複数のブロックデバイスにまたがる論理的な
パーティションを扱えます。
</para></footnote>
<!--
within that disk.
-->
の内の 1 つを指しています。
</para>
<para>
<!--
The remaining 7 SCSI disk block major numbers follow a similar pattern:
-->
残りの 7 つのSCSI ディスクブロックのメジャー番号は、同じようなパターン
をとります。
<programlisting>
[b,65,0]   /dev/sdq
[b,65,1]   /dev/sdq1
....
[b,65,159] /dev/sdz15
[b,65,160] /dev/sdaa
[b,65,161] /dev/sdaa1
....
[b,65,255] /dev/sdaf15
[b,66,0]   /dev/sdag
[b,66,1]   /dev/sdag1
....
[b,66,255] /dev/sdav15
....
[b,71,255] /dev/sddx15
</programlisting>
</para>
<para>
<!--
So there are 128 possible disks (i.e. <filename>/dev/sda</filename> to
<filename>/dev/sddx</filename>) each having up
to 15 partitions. By way of contrast, the IDE subsystem allows 20 disks
(10 controllers each with 1 master and 1 slave) which can have up to 63
partitions each.
-->
したがって、最大 128 個のディスクがあり(つまり <filename>/dev/sda</filename> 
から <filename>/dev/sddx</filename> まで)、それぞれ、15 個までのパーティション
を持てます。これに対して IDE サブシステムは、20 個のディスク(10 個の
コントローラそれぞれにマスター 1 つ、スレーブ 1 つ)を持ち、それぞれが 63 
パーティションを持てます。
</para>
<para>
<!--
SCSI CD-ROM devices are allocated the block major number of 11. Traditionally
<filename>sr</filename> has been the device name but <filename>scd</filename>
probably is more recognizable and is
favoured by several recent distributions. 256 SCSI CD-ROM devices are
allowed:
-->
SCSI の CD-ROM デバイスには、ブロックメジャー番号の 11 が割り当てられて
います。
従来は <filename>sr</filename> がデバイス名でしたが、おそらく 
<filename>scd</filename> の方がなじみ深いでしょうし、最近の
ディストリビューションのいくつかはこちらを選んでいます。256 個の CD-ROM 
デバイスが付けられます。
<programlisting>
[b,11,0]   /dev/scd0          [or /dev/sr0]
[b,11,255] /dev/scd255        [or /dev/sr255]
</programlisting>
</para>
<para>
<!--
SCSI tape devices are allocated the char major number of 9. Up to 32 tape
devices are supported each of which can be accessed in one of four modes
(0, 1, 2 and 3), with or without rewind. The devices are allocated as
follows:
-->
SCSI テープは、キャラクタメジャー番号の 9 が割り当てられています。
32 個のテープデバイスをサポートしており、各デバイスには 4 つのモード
(0、1、2、3)のどれかでアクセスでき、さらにリワインドの有無を指定できます。
デバイスは次のように割り当てます。
<programlisting>
[c,9,0]    /dev/st0     [tape 0, mode 0, rewind]
[c,9,1]    /dev/st1     [tape 1, mode 0, rewind]
....
[c,9,31]   /dev/st31    [tape 31, mode 0, rewind]
[c,9,32]   /dev/st0l    [tape 0, mode 1, rewind]
....
[c,9,63]   /dev/st31l   [tape 31, mode 1, rewind]
[c,9,64]   /dev/st0m    [tape 0, mode 2, rewind]
....
[c,9,96]   /dev/st0a    [tape 0, mode 3, rewind]
....
[c,9,127]  /dev/st31a   [tape 31, mode 3, rewind]
[c,9,128]  /dev/nst0    [tape 0, mode 0, no rewind]
....
[c,9,160]  /dev/nst0l   [tape 0, mode 1, no rewind]
....
[c,9,192]  /dev/nst0m   [tape 0, mode 2, no rewind]
....
[c,9,224]  /dev/nst0a   [tape 0, mode 3, no rewind]
....
[c,9,255]  /dev/nst31a  [tape 31, mode 3, no rewind]
</programlisting>
</para>
<para>
<!--
The SCSI generic (sg) devices are allocated the char major number of 21.
There are 256 possible SCSI generic (sg) devices:
-->
SCSI 汎用デバイス(sg)には、キャラクタメジャー番号の 21 に割り当てられて
います。
最大 256 個の SCSI 汎用デバイス(sg)が持てます。
<programlisting>
[c,21,0]   /dev/sg0
[c,21,1]   /dev/sg1
....
[c,21,255] /dev/sg255
</programlisting>
</para>
<para>
<!--
Note that the SCSI generic device name's use of a trailing letter (e.g.
<filename>/dev/sgc</filename>) is deprecated.
-->
SCSI 汎用デバイスの名前の最後に文字が付くもの(例えば <filename>/dev/sgc
</filename>)は、旧い形式です。
</para>
<para>
<!--
Each SCSI disk (but not each partition), each SCSI CD-ROM and each SCSI
tape is mapped to an sg device. SCSI devices that don't fit into these
three categories (e.g. scanners) also appear as sg devices.
-->
SCSI ディスクと SCSI CD-ROM、SCSI テープは、何らかの sg デバイスにマップ
されています(ただしディスクの各パーティションはマップされていません)。この 
3 つのカテゴリいずれでもない SCSI デバイス(例えばスキャナー)も、sg デバイス
として見えます。

</para>
<para>
<!--
Pseudo devices [see <xref linkend="llevelpseudo"/>] can cause devices
that are usually not considered as SCSI to appear as SCSI device names.
For example an ATAPI CD-ROM may be picked up by the ide-scsi pseudo
driver and mapped to <filename>/dev/scd0</filename> .
-->
擬似デバイス(<xref linkend="llevelpseudo"/>を参照)は、通常 SCSI とは見なさ
ないデバイスを SCSI デバイス名として表示します。
例えば ATAPI CD-ROM は ide-scsi 擬似ドライバで動作し、<filename>/dev/scd0
</filename>にマップされます。
</para>
<para>
<!--
The <filename>linux/Documentation/devices.txt</filename> file supplied
within the kernel source is the definitive reference for Linux device
names and their corresponding major and minor number allocations.
-->
Linux のデバイス名とそれに対応したメジャー、マイナー番号の割り当てに
ついては、カーネルソースとともに配布されている
<filename>linux/Documentation/devices.txt</filename> が信頼できる
リファレンスになっています。
</para>
</sect1>

<sect1 id="dnamesdevfs">
      <!--
  		<title>Device Names in devfs</title>
  		-->
  		<title>devfs でのデバイス名</title>
<para>
<!--
The device pseudo file system can be mounted as <filename>/dev</filename> in
which case it replaces the traditional Linux device subdirectory.
Alternatively it can be mounted elsewhere (e.g. <filename>/devfs</filename>)
and supplement the existing device structure.
-->
デバイス擬似ファイルシステムは <filename>/dev</filename> にマウントでき、
こうすると従来の Linux デバイスのサブディレクトリに置き換わります。
あるいは別の場所(例えば <filename>/devfs</filename>)にマウントすることも可能
で、既存のデバイス構造へ追加も可能です。
</para>
<para>
<!--
Without devfs, devices names are typically maintained in the
<filename>dev</filename> directory
of the root partition. Hence the device names (and their associated
permissions) have file system persistence. The existence of a device name
does not necessarily imply such a device (or even its driver) is present. To
save users having to create device name entries (with the <command>mknod
</command> command) most Linux distributions come with thousands of device
names defined in the <filename>/dev</filename> directory. When applications
try to open() the device name then an errno value of ENODEV indicates there
is no corresponding device (or driver) currently available.
-->
devfs を使わないと、通常デバイス名はルートパーティションの 
<filename>dev</filename> ディレクトリ内で扱われます。したがって、デバイス名
(およびそのパーミッション)は、ファイル・システムと同じ永続性を持ちます。
デバイス名があっても、必ずしもデバイス(もしくはそのデバイスのドライバさえ)が
その時に存在するわけではありません。ユーザがデバイス名のエントリーを作成する
手間(<command>mknod</command>を使って)を省くため、ほとんどの Linux 
ディストリビューションには何千ものデバイス名が <filename>/dev</filename> 
ディレクトリに入っています。アプリケーションがデバイス名を open() しようとした
時にerrno 値 ENODEV が返された場合は、対応するデバイス(もしくはドライバ)がその
時に利用できないことを示します。
</para>
<para>
<!--
Devfs takes a different approach in which the existence of the device name
is directly related to the presence of the corresponding device (and its
driver).
-->
devfs は違った方法をとります。デバイス名が存在すれば、すなわち対応する
デバイス(とドライバ)が存在することを意味します。
</para>
<para>
<!--
Assuming devfs is mounted on <filename>/dev</filename> then SCSI devices
have primary device names that might look like this:
-->
devfs を <filename>/dev</filename> にマウントしている場合、SCSI デバイス
のプライマリーデバイス名はこのようになります。
<programlisting>
<!--
/dev/scsi/host0/bus0/target1/lun0/disc    [whole disk]
/dev/scsi/host0/bus0/target1/lun0/part6   [partition 6]
/dev/scsi/host0/bus0/target1/lun0/generic [sg device for disk]

/dev/scsi/host1/bus0/target2/lun0/cd      [CD reader or writer]
/dev/scsi/host1/bus0/target2/lun0/generic [sg device for cd]

/dev/scsi/host2/bus0/target0/lun0/mt      [tape mode 0 rewind]
/dev/scsi/host2/bus0/target0/lun0/mtan    [tape mode 3 no rewind]
/dev/scsi/host2/bus0/target0/lun0/generic [sg device for tape]
-->
/dev/scsi/host0/bus0/target1/lun0/disc    [ディスク全体]
/dev/scsi/host0/bus0/target1/lun0/part6   [パーティション 6]
/dev/scsi/host0/bus0/target1/lun0/generic [sg デバイスのディスク]

/dev/scsi/host1/bus0/target2/lun0/cd      [CD リーダーもしくは CD ライター]
/dev/scsi/host1/bus0/target2/lun0/generic [sg デバイスの CD]

/dev/scsi/host2/bus0/target0/lun0/mt      [テープ モード 0 リワインド]
/dev/scsi/host2/bus0/target0/lun0/mtan    [テープ モード 3 リワインドなし]
/dev/scsi/host2/bus0/target0/lun0/generic [sg デバイスのテープ]
</programlisting>
<!--
The sg device on the third line corresponds to the "whole disk" on the
first line since they have the same SCSI address (i.e.
<filename>host0/bus0/target1/lun0</filename>). If the sg driver is a module
and it has not yet been loaded (or it has been unloaded) then the
"generic" device names in the above list will not be present.
-->
3 行目の sg デバイスは、1 行目にある「ディスク全体」に対応しており、
この両者は同じアドレス(つまり
<filename>host0/bus0/target1/lun0</filename>)を指します。
sg ドライバがモジュールでまだロードされていない(もしくはアンロード
されている)場合、上記のリストにある「generic」デバイス名は現れません。
</para>
<para>
<!--
[Notice the spelling of "disc" as the devfs author favours English spelling
over the American variant.] It can be seen that devfs's naming scheme
closely matches the SCSI addressing discussed in
<xref linkend="scsiaddr"/>. It is worth noting that the IDE subsystem uses
a similar devfs device naming scheme with the word "scsi" replaced with
"ide". Devfs is discussed further in <xref linkend="devfs"/>.
-->
(「disc」というスペルに注意。devfs の開発者は、米語のこの綴りがお気に入り)。
devfs の名前付け規則は、<xref linkend="scsiaddr"/>で論じている SCSI の
アドレス付けにぴったりマッチしていることがわかるでしょう。IDE サブシステム
が同じような(「scsi」という単語を「ide」に置き換えた)規則で devfs デバイスを
名付けている点も覚えておくと良いと思います。devfs は<xref linkend="devfs"/>
でさらに論じます。
</para>
</sect1>

<sect1 id="dnamesscsidev">
      <!--
  		<title>Device Names in scsidev</title>
  		-->
  		<title>scsidev におけるデバイス名</title>
<para>
<!--
A utility program called <command>scsidev</command> adds device names to
the <filename>/dev/scsi</filename> directory that reflect the SCSI address
of each device. The first 2 letters of the name are the upper level SCSI
driver name (i.e. either sd, sr, st or sg). The number following the "h"
is the host number while the number following the "-" is meant for
host identification purposes. For PCI adapters this seems to be always
0 while for ISA adapters it is their IO address. [Perhaps this field
could be made more informative or dropped.] The numbers following
the "c", "i" and "l" are channel (bus), target id and lun values
respectively. Raw disks are shown without a trailing partition number
while partitions contained within them are shown with the partition
number following a "p".
-->
<command>scsidev</command>と呼ばれているユーティリティプログラムは、
デバイス名を <filename>/dev/scsi</filename> ディレクトリに追加します。
そのデバイス名は、各デバイスの SCSI アドレスを反映しています。最初の 2 文字は
上位レベルの SCSI ドライバの名前(例えば sd や sr、st、sg)です。
「h」の後の数字はホスト番号で、その後の「-」はホスト識別用の番号です。
PCI のアダプタではこの数字は常に 0 のようですが、ISA アダプタではその IO 
アドレスになります。(おそらくこのフィールドには、さらに情報が入るかも
しれませんし、無くなるかもしれません)。「c」や「i」、「l」の後にある数字は、
それぞれチャネル(バス)とターゲット ID、LUN の値になります。raw ディスクは
「p」とパーティション番号が付きません。その内部に含まれる各パーティションには、
「p」とパーティション番号が付きます。
</para>
<para>【訳註：図にすると下記のようになります
</para>
<para>
<programlisting>
sd  h0  -  0  c0  i0  l0  p1
==  ==  =  =  ==  ==  ==  ===
|   |   |  |   |   |   |   |
|   |   |  |   |   |   |  パーティション番号は 1
|   |   |  |   |   |   |
|   |   |  |   |   |  LUN は 0
|   |   |  |   |   |
|   |   |  |   |  ターゲット ID は 0
|   |   |  |   |
|   |   |  |  バス(チャネル)番号は 0
|   |   |  |
|   |   |  PCI なら 0, ISA なら I/O アドレス
|   |   |
|   |  固定
|   |
|  ホスト番号は 0
|
上位レベルの SCSI ドライバの名前
</programlisting> 】
</para>
<para>
<!--
The <command>scsidev</command> would typically be run as part of the
boot up sequence. It may also be useful to run it after the SCSI
configuration has changed (e.g. adding or removing lower level driver
modules, or the use of the add/remove-single-device command). After
<command>scsidev</command> has been run on my system which contains
2 disks, a cd reader and writer plus a scanner, then the following
names were added in the <filename>/dev/scsi</filename> directory:
-->
<command>scsidev</command> は、ブートシーケンスの一部として動くのが
普通です。SCSI の設定が変更になった後に動かすのも良いでしょう(例えば
低レベルのドライバモジュールを追加・削除したり、add/remove-single-device 
コマンドを使ったりする時)。<command>scsidev</command> を私のシステムで実行
した時に <filename>/dev/scsi</filename> ディレクトリへ追加された名前を挙げます。
私のシステムには、ディスク 2 つ、CD-R ドライブ 1 台、スキャナー 1 台が付いて
います。
<programlisting>
$ ls -l /dev/scsi/   # abridged
total 0
brw-------  8,   0 Sep  2 11:56 sdh0-0c0i0l0
brw-------  8,   1 Sep  2 11:56 sdh0-0c0i0l0p1
...
brw-------  8,   8 Sep  2 11:56 sdh0-0c0i0l0p8
brw-------  8,  16 Sep  2 11:56 sdh0-0c0i1l0
brw-------  8,  17 Sep  2 11:56 sdh0-0c0i1l0p1
...
brw-------  8,  24 Sep  2 11:56 sdh0-0c0i1l0p8
crw------- 21,   0 Sep  2 11:56 sgh0-0c0i0l0
crw------- 21,   1 Sep  2 11:56 sgh0-0c0i1l0
crw------- 21,   2 Sep  2 11:56 sgh1-0c0i2l0
crw------- 21,   3 Sep  2 11:56 sgh1-0c0i5l0
crw------- 21,   4 Sep  2 11:56 sgh1-0c0i6l0
br-------- 11,   0 Sep  2 11:56 srh1-0c0i2l0
br-------- 11,   1 Sep  2 11:56 srh1-0c0i6l0
</programlisting>
<!--
The mapping between the SCSI generic device names (sg) and their corresponding
names when controlled by other upper level drivers (i.e. sd, sr or st) can
be seen by looking for name matches when the second letter is ignored.
Hence "sdh0-0c0i0l0" and "sgh0-0c0i0l0" refer to the same device. By process
of elimination the "sgh1-0c0i5l0" filename is the scanner since that class
of devices can only be accessed via the sg interface.
-->
SCSI 汎用デバイス名(sg)と、そのデバイスが他の高レベルドライバ(例えば sd、sr、
st)で制御された場合の名前との対応は、2 番目の文字を無視してマッチする名前
を探せばわかります。
消去法でいくと、「sgh1-0c0i5l0」というファイル名はスキャナーとわかります。
このデバイスには sg インタフェース経由でしかアクセスできないからです。
</para>
<para>
<!--
The scsidev package also includes the ability to introduce names like
<filename>/dev/scsi/scanner</filename> by manipulating the <filename>
/etc/scsi.alias</filename> configuration file. The package also includes
the useful <command>rescan-scsi-bus.sh</command> utility.
For further information about <command>scsidev</command> see
<link linkend="W6">W6</link>. On my system, both devfs and scsidev
co-exist happily.
-->
scsidev パッケージは <filename>/etc/scsi.alias</filename> という設定ファイル
を扱い、<filename>/dev/scsi/scanner</filename>というような名前を付ける機能も
あります。パッケージには、<command>rescan-scsi-bus.sh</command> という便利な
ユーティリティもあります。
<command>scsidev</command> についてのさらに詳しい情報は<link linkend="W6">
W6</link>を見てください。私のシステムでは、devfs と scsidev は何の問題も無く
共存しています。
</para>

</sect1>
</chapter>

<chapter id="kconfig">
      <!--
  		<title>Kernel Configuration</title>
  		-->
  		<title>カーネルの設定</title>
<para>
<!--
The Linux kernel configuration is usually found in the kernel source in
the file: <filename>/usr/src/linux/.config</filename> . It is not
recommended to edit this file directly but to use one of these configuration
options:
-->
Linux カーネルの設定は、通常カーネルソースの
<filename>/usr/src/linux/.config</filename> というファイルにあります。
このファイルは直接いじるのではなく、下記のカーネル設定オプション のどれかを
利用することをお勧めします。
<itemizedlist>
<!--
<listitem><para><command>make config</command> - starts a character based
questions and answer session</para></listitem>
<listitem><para><command>make menuconfig</command> - starts a
terminal-oriented configuration tool (using ncurses)</para></listitem>
<listitem><para><command>make xconfig</command> - starts a
X based configuration tool</para></listitem>
-->
<listitem><para><command>make config</command>−キャラクタベースで質問
形式で行う</para></listitem>
<listitem><para><command>make menuconfig</command>−端末指向の設定ツール
(ncurses を使用)で行う</para></listitem>
<listitem><para><command>make xconfig</command>−X ベースの設定ツールで行う
</para></listitem>
</itemizedlist>
</para>
<para>
<!--
The descriptions of these selections that is displayed by the associated
help button can be found in the flat ASCII file:
<filename>/usr/src/linux/Documentation/Configure.help</filename>
-->
選択肢の説明は、それぞれのヘルプボタンで表示されます。この内容は ASCII 
ファイル <filename>/usr/src/linux/Documentation/Configure.help</filename> 
に含まれています。
</para>
<para>
<!--
Ultimately these configuration tools edit the <filename>.config</filename>
file. An option will either indicate some driver is built into the
kernel ("=y") or will be built as a module ("=m") or is not selected.
The unselected state can either be indicated by a line starting with
"#" (e.g. "# CONFIG_SCSI is not set") or by the absence of the relevant
line from the <filename>.config</filename> file.
-->
詰まるところ、これらの設定ツールは <filename>.config</filename> ファイルを編集
しています。選択肢は、ドライバがカーネルに組み込まれる(「=y」)、モジュール
として作成される(「=m」)、選択しない、のどれかです。
選択していない状態には、行の先頭に「#」(例えば「# CONFIG_SCSI」は未設定を表す)
がある場合と、<filename>.config</filename> ファイルに関連する行が無い場合とが
あります。
</para>
<para>
<!--
The 3 states of the main selection option for the SCSI subsystem (which
actually selects the SCSI mid level driver) follow. Only one of these
should appear in an actual <filename>.config</filename> file:
-->
SCSI サブシステム(正確には SCSI の中間レベルのドライバ)の主なオプションは、
下記の 3 つのいずれかです。この中の 1 つだけが実際に 
<filename>.config</filename> ファイル中にあるはずです。
<programlisting>
CONFIG_SCSI=y
CONFIG_SCSI=m
# CONFIG_SCSI is not set
</programlisting>
</para>
<para>
<!--
Some other common SCSI configuration options are:
-->
その他、一般的な SCSI の設定オプションは下記の通りです。
<programlisting>
<!--
CONFIG_BLK_DEV_SD        [disk (sd) driver]
CONFIG_SD_EXTRA_DEVS     [extra slots for disks added later]
CONFIG_BLK_DEV_SR        [SCSI cdrom (sr) driver]
CONFIG_BLK_DEV_SR_VENDOR [allow vendor specific cdrom commands]
CONFIG_SR_EXTRA_DEVS     [extra slots for cdroms added later]
CONFIG_CHR_DEV_ST        [tape (st) driver]
CONFIG_CHR_DEV_OSST	 [OnSteam tape (osst) driver]
CONFIG_CHR_DEV_SG        [SCSI generic (sg) driver]
CONFIG_DEBUG_QUEUES      [for debugging multiple queues]
CONFIG_SCSI_MULTI_LUN    [allow probes above lun 0]
CONFIG_SCSI_CONSTANTS    [symbolic decode of SCSI errors]
CONFIG_SCSI_LOGGING      [allow logging to be runtime selected]

CONFIG_SCSI_&lt;ll_driver>  [numerous lower level adapter drivers]
CONFIG_SCSI_DEBUG        [lower level driver for debugging]

CONFIG_SCSI_PPA          [older parallel port zip drives]
CONFIG_SCSI_IMM          [newer parallel port zip drives]

CONFIG_BLK_DEV_IDESCSI   [ide-scsi pseudo adapter]
CONFIG_I2O_SCSI		 [scsi command set over i2o bus]
CONFIG_SCSI_PCMCIA       [for SCSI HBAs on PCMCIA bus]
CONFIG_USB_STORAGE       [usb "mass storage" type]

CONFIG_MAGIC_SYSRQ       [Alt+SysRq+S for emergency sync]
                         [Alt+SyrRq+U for emergency remount ro]
-->
CONFIG_BLK_DEV_SD        [ディスク(sd)ドライバ]
CONFIG_SD_EXTRA_DEVS     [追加で入れるディスク用の増設スロット]
CONFIG_BLK_DEV_SR        [SCSI CD-ROM(sr)ドライバ]
CONFIG_BLK_DEV_SR_VENDOR [CD-ROM のベンダー独自コマンドを許可]
CONFIG_SR_EXTRA_DEVS     [追加で入れる CD-ROM 用の増設スロット]
CONFIG_CHR_DEV_ST        [テープ(st)ドライバ]
CONFIG_CHR_DEV_OSST	 [OnSteam 社 テープ(osst) ドライバ]
CONFIG_CHR_DEV_SG        [SCSI 汎用ドライバ(sg)]
CONFIG_DEBUG_QUEUES      [複数のキューのデバッグ用]
CONFIG_SCSI_MULTI_LUN    [0 以上の LUN のプルーブの許可]
CONFIG_SCSI_CONSTANTS    [SCSI のエラー記号の復号]
CONFIG_SCSI_LOGGING      [実行時選択のログ収集許可]

CONFIG_SCSI_&lt;ll_driver>  [種々の低レベルのアダプタドライバ]
CONFIG_SCSI_DEBUG        [デバッグ用低レベルドライバ]

CONFIG_SCSI_PPA          [旧式のパラレルポート zip ドライバ]
CONFIG_SCSI_IMM          [新式のパラレルポート zip ドライバ]

CONFIG_BLK_DEV_IDESCSI   [ide-scsi 擬似アダプタ]
CONFIG_I2O_SCSI		 [I2O バス経由の SCSI コマンド・セット]
CONFIG_SCSI_PCMCIA       [PCMCIA バス経由の SCSI HBA]
CONFIG_USB_STORAGE       [USB「大容量」タイプ]

CONFIG_MAGIC_SYSRQ       [緊急時の sync 用 Alt+SysRq+S]
                         [緊急時の ro 再マウント用 Alt+SyrRq+U]
</programlisting>
</para>
<para>
<!--
If the root file system is on a SCSI disk then it makes sense
to build into the kernel the SCSI mid level, the sd driver and
the host adapter driver that the disk is connected to. In most cases
it is usually safe to build the sr, st and sg drivers as modules so
that they are loaded as required. If a device like a scanner is on
a separate adapter then its driver may well be built as a module. In
this case, that adapter driver will need to be loaded before the
scanner will be recognized.
-->
ルートファイルシステムが SCSI ディスクなら、カーネルに SCSI の中間
レベルのドライバ、sd ドライバ、そのディスクがつながっている
アダプタのドライバを必ず組み込んでください。たいていの場合、sr、st、sg などの
ドライバはモジュールとして作成してかまいません。それらのドライバは必要になると
ロードされます。スキャナーのようなデバイスが別のアダプタに接続されている
なら、そのドライバはモジュールとして作成した方が良いでしょう。この場合アダプタ
・ドライバは、スキャナーが認識される前にロードしなければなりません。
</para>
<para>
<!--
Linux distributions have many of the SCSI subsystem drivers built as
modules since building all of them in would lead to a very
large kernel that would exceed the capabilities of the boot loader.
This leads to a "chicken and the egg" problem in which the SCSI
drivers are needed to load the root file system and vice versa. The
2 phase load used by the initrd device addresses this problem
(see <xref linkend="modparams"/> for more details).
-->
Linux ディストリビューションには、SCSI サブシステムのドライバがモジュール
としてたくさん入っています。理由は、すべてをカーネルに組み込むと巨大になって
しまい、ブートローダーの能力を越えてしまうかもしれないからです。
これは、「鶏が先か、卵が先か」問題の原因になります。ルートファイルシステムを
ロードするには SCSI ドライバが必要になりますが、ドライバをロードするには
ルートファイルシステムをマウントしなければいけません。
この問題には、ロード時に 2 段階を踏む initrd デバイスで対処ができます。
(詳細は、<xref linkend="modparams"/>を参照)。
</para>
</chapter>

<chapter id="bparams">
      <!--
  		<title>Boot Parameters</title>
  		-->
  		<title>ブート時のパラメタ</title>
<para>
<!--
On a PC the motherboard's BIOS together with the SCSI BIOS provided
by most SCSI host adapters takes care of the problem of loading the
boot loader's image from a SCSI disk into memory and executing it. This
may require some settings to be changed in the motherboard's BIOS. When
more than one SCSI adapter is involved, the SCSI BIOS settings may need
to change to indicate which one contains the disk with the boot image.
The boot image make also come from an ATA (IDE) disk, a bootable CD-ROM or
a floppy.
-->
PC では、マザーボード上の BIOS と SCSI ホストアダプタの大部分が提供して
いる SCSI BIOS とが協調し、SCSI ディスク上にあるブートローダーのイメージを
メモリにロード・実行する処理を行っています。こうするには、マザーボード上の 
BIOS の設定を何かしら変更する必要があるかもしれません。
1 つ以上の SCSI アダプタがある場合には、SCSI BIOS の設定を変更して、ブート
イメージがあるディスクがつながっているアダプタを示してやる必要があるかも
しれません。
ブートイメージが ATA(IDE)ディスクやブータブルな CD-ROM、フロッピー・
ディスクに存在する場合もあります。
</para>
<para>
<!--
Both <emphasis>lilo</emphasis> and <emphasis>grub</emphasis> are commonly 
used boot loaders with Linux. Their configuration files are in 
<filename>/etc/lilo.conf</filename> and <filename>/etc/grub.conf</filename>
-->
Linux のブートローダーで良く使われるのは、<emphasis>lilo</emphasis>
と <emphasis>grub</emphasis> です。設定ファイルは、それぞれ 
<filename>/etc/lilo.conf</filename> と <filename>/etc/grub.conf</filename> 
です。
<footnote><para>
<!--
One slight wrinkle with grub is that <filename>/etc/grub.conf</filename> is
a symbolic link to <filename>/boot/grub/grub.conf</filename>. This can be
useful to know when <filename>/boot</filename> is a separate partition.
-->
grub のちょっとした工夫の 1 つは、<filename>/etc/grub.conf</filename> が
<filename>/boot/grub/grub.conf</filename> へのシンボリックリンクである点
です。これは <filename>/boot</filename> が別パーティションになっている場合に、
知っておくと便利かもしれません。
【訳註： grub.conf、menu.list の位置や存在は、ディストリビューションによって
変わるようです】
</para></footnote>
<!--
respectively. One difference is that after changing lilo's configuration the
<command>lilo</command> command must be executed for the changes to take 
effect (and there is no equivalent requirement for grub). See their "man" 
pages for usage information. An excellent paper on lilo and the Linux bootup
sequence can be found
<ulink url="ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz">
<literal>ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz</literal></ulink>.
For further information on grub see 
<ulink url="http://www.gnu.org/software/grub">
<literal>www.gnu.org/software/grub</literal></ulink>.
-->
両者の違いの 1 つは、lilo で設定を変更した後、その設定を有効にするために 
<command>lilo</command> コマンドを実行する点です(grub ではそのような作業は
不要)。使い方は man ページを見てください。
lilo と Linux のブートシーケンスについては素晴らしい論文があります。
<ulink url="ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz">
<literal>ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-0.ps.gz</literal></ulink> 
です。
grub については以下を御覧下さい。
<ulink url="http://www.gnu.org/software/grub">
<literal>www.gnu.org/software/grub</literal></ulink>。
</para>
<para>
<!--
Some boot parameters related to the SCSI subsystem:
-->
SCSI サブシステムに関連したブート時のパラメタは、下記の通りです。
<programlisting>
 <!--
 single         [enter single user mode]
 &lt;n>            [enter run level &lt;n> {0..6}]
 root=/dev/sda6 [*]
 root=/dev/scsi/host0/bus0/target0/lun0/part6 [*]
 root=/dev/sd/c0b0t0u0p6   [*]
 devfs=mount    [overrides CONFIG_DEVFS_MOUNT=n]
 devfs=nomount  [overrides CONFIG_DEVFS_MOUNT=y]
 init=&lt;command> [executes &lt;command> rather than init]
 quiet          [reduce output to console during boot]
 debug          [increase output to console during boot]
 nmi_watchdog=0 [turn off NMI watchdog on a SMP machine]
 max_scsi_luns=1  [limits SCSI bus scans to lun==0]
 -->
 single         [シングルユーザーモードへ]
 &lt;n>            [ランレベルを &lt;n> {0..6} へ]
 root=/dev/sda6 [*]
 root=/dev/scsi/host0/bus0/target0/lun0/part6 [*]
 root=/dev/sd/c0b0t0u0p6   [*]
 devfs=mount    [CONFIG_DEVFS_MOUNT=n を上書き]
 devfs=nomount  [CONFIG_DEVFS_MOUNT=y を上書き]
 init=&lt;command> [init ではなく、&lt;command> の実行]
 quiet          [ブート時コンソール出力メッセージの抑制]
 debug          [ブート時コンソール出力メッセージの詳細化]
 nmi_watchdog=0 [SMP マシン上での NMI watchdog を停止]
 max_scsi_luns=1  [LUN が 0 に対してのみ SCSI バススキャンを行う]
</programlisting>
<!--
* When devfs is in use the initial read-only mount
of the root partition can be done via the old
/dev/sd&lt;a>&lt;n> notation or the new devfs
notation (and two of these are shown). 
The joint "root=/dev/sda6 single" may be useful
when disk or adapter changes have broken the
kernel boot load.
-->
*  devfs を使っている場合、最初にリード・オンリーでルートパーティションを
マウントする時は、これまでの /dev/sd&lt;a>&lt;n> という表記とともに新しい 
devfs の表記も使用できます(ここでは両方示してあります)。
「root=/dev/sda6  single」という組み合わせは、ディスクもしくはアダプタ 
の変更によって、カーネルブート時のロードがおかしくなった時に役に立つでしょう。
</para>
<para>
<!--
The "root=" argument may also be a hex number. For example, if the root
partition is on <filename>/dev/sda3</filename> then "root=803" is 
appropriate. The last two digits are the minor device number discussed
in an earlier section.
-->
「root=」の引数は 16 進数でも指定できます。例えばルートパーティションが 
<filename>/dev/sda3</filename> にあれば、「root=803」が適切な表記となります。
後の 2 桁が以前の節で述べたマイナーデバイス番号です。
</para>
<para>
<!--
The default argument to the "init" parameter is <filename>/sbin/init
</filename> (see man (8) init). If files such as <filename>/etc/fstab
</filename> have incorrect entries, it may be useful to drop directly
into a shell with "init=/bin/bash". However if shared libraries files
or their paths are inappropriate this may also fail. That leaves
"init=/sbin/sash" which is a statically linked shell with many useful
commands (for repairing a system) built in (see man (8) sash).
-->
「init」パラメタのデフォルトの引数は <filename>/sbin/init</filename> 
です(man 8 の init を参照)。<filename>/etc/fstab</filename> のような
ファイルに間違った項目があった場合は、「init=/bin/bash」でシェルに
直接落ちた方が便利でしょう。しかし共有ライブラリのファイルやそのパスが
適切でないと、これも失敗するかもしれません。そういう場合は、「init=/sbin/sash」
としましょう。これは静的にリンクされたシェルで、システムの修復に役立つ様々な
コマンドが入っています(man 8 sash を参照)。
</para>
<para>
<!--
When Linux fails to boot after reporting a message like:
-->
Linux は次のようなメッセージを出してブートに失敗することがあります。
<programlisting>
  VFS: Cannot open root device 08:02
</programlisting>
<!--
then the kernel expected to find a root partition on device
<filename>/dev/sda2</filename> and did not. The numbers in the
error message are major and minor device numbers (in hex)
[see <xref linkend="dnames"/> for
the mapping to device names]. In such situations the "root" boot option
can be useful (also the <command>rdev</command> command can be used to
modify where the boot image looks for the root partition).
-->
これは、カーネルが <filename>/dev/sda2</filename> デバイスにルート
パーティションがあることを期待したのに、そこにはなかったことを意味します。
エラーメッセージ中の数字は、デバイスのメジャー、マイナー番号(16 進数)
です(デバイス名のマッピングについては<xref linkend="dnames"/>を参照)。
このような場合は「root」ブート・オプションが便利です(ブートイメージが
ルートパーティションを探す場所を変更するには <command>rdev</command> 
コマンドも使えます)。
</para>
<para>
<!--
Lilo's configuration file <filename>/etc/lilo.conf</filename>
can take the "root=" option in two ways. The normal way is a line
like: 'root=/dev/sda2'.
In this case <filename>/dev/sda2</filename> is converted into major
and minor numbers based on the state of the system <emphasis>when
</emphasis> the <command>lilo</command> command is executed. This can be
a nuisance, especially if hardware is going to be re-arranged.
The other way is a line of the form: 'append="root=/dev/sda2"'
In this case the <filename>/dev/sda2</filename> is passed through
to the kernel the next time it is started. This is the same as
giving the "root=/dev/sda2" string at the kernel boot time prompt.
It is interpreted by the kernel at startup (once the HBAs and their
attached devices have been recognized) and thus is more flexible.
-->
lilo の設定ファイル <filename>/etc/lilo.conf</filename> で「root=」オプション
を指定するには 2 つの方法があります。通常は「root=/dev/sda2」という行を入れ
ます。
この場合、<command>lilo</command> コマンドを<emphasis>実行した時</emphasis>
のシステムの状態に基づいて、<filename>/dev/sda2</filename> はメジャー、
マイナー番号に変換されます。これは特にハードウェア構成を変更する場合には
やっかいなことになりかねません。
もう一つの方法は、「append="root=/dev/sda2"」という行を入れる方法です。
この場合、<filename>/dev/sda2</filename> はカーネルが次に起動する時に渡され
ます。これはカーネルブート時に「root=/dev/sda2」文字列をコマンドライン
のプロンプトに渡すのと同じです。
起動時にカーネルが解釈しますので(HBA と HBA に接続しているデバイスが認識されて
いれば)、より柔軟に扱えます。
</para>
</chapter>

<chapter id="modparams">
      <!--
  		<title>Modules and their Parameters</title>
  		-->
  		<title>モジュールとそのパラメタ</title>
<para>
<!--
There are many SCSI related modules. The mid and upper level modules
are listed below:
-->
SCSI 関連のモジュールはたくさんあります。中間と上位レベルのモジュール
を次に挙げます。
<itemizedlist>
<listitem><para> scsi_mod.o </para></listitem>
<listitem><para> sd_mod.o </para></listitem>
<listitem><para> sr_mod.o </para></listitem>
<listitem><para> st.o [osst.o] </para></listitem>
<listitem><para> sg.o </para></listitem>
</itemizedlist>
</para>
<para>
<!--
Notice that the first 3 have "_mod" appended to their normal driver names.
Lower level drivers tend to use the name (or an abbreviation) of the
HBA's manufacturer (e.g. advansys)
plus optionally the chip number of the major controller chip (e.g.
sym53c8xx for symbios controllers based on the NCR 53c8?? family of chips).
-->
最初の 3 つは、通常のドライバ名に「_mod」が付いている点に注意してください。
低レベルのドライバには、HBA の製造メーカーの名前またはその略称(例えば 
advansys)に加えて、主要な制御用チップのチップ番号が付くこともあります
(例えば sym53c8xx は NCR 53c8?? 系のチップが載っている symbios 
のコントローラ)。
</para>
<para>
<!--
All SCSI modules depend on the mid level. This means if the SCSI mid
level is not built into the kernel and if <filename>scsi_mod.o</filename>
has not already been loaded then a command like <command>modprobe st</command>
will cause the <filename>scsi_mod.o</filename> module to be loaded. There
could well be other dependencies, for example <command>modprobe sr_mod
</command> will also cause the cdrom module to be loaded if it hasn't been
already. Also if the SCSI mid level is a module, then all other SCSI
subsystem drivers must be modules (this is enforced by the kernel build
configuration tools).
-->
SCSI モジュールはすべて、中間レベルのドライバに依存しています。
SCSI の中間レベルドライバがカーネルに組み込まれておらず、かつ 
<filename>scsi_mod.o</filename> がロードされていない場合、
<command>modprobe st</command> のようなコマンドが 実行されると、
<filename>scsi_mod.o</filename> モジュールがロードされることになります。
おそらく他にも依存関係があるはずで、例えば <command>modprobe sr_mod</command> 
とすれば、CD-ROM のモジュールが(まだロードされていなければ)ロードするでしょう。
また、SCSI の中間レベルがモジュールなら、SCSI サブシステムのその他すべての
ドライバもモジュールでなければいけません(これはカーネル構築の設定ツール 
で強制されます)。
</para>
<para>
<!--
Modules can be loaded with the <command>modprobe &lt;module_name>
</command> command which will try to load any modules that the
nominated &lt;module_name> depends on.
Also &lt;module_name> does not need the trailing ".o" extension which
is assumed if not given. The <command>insmod &lt;module_name></command>
command will also try
and load &lt;module_name> but without first loading modules it depends on.
Rules for how modules can cause other modules to be loaded (with
appropriate parameters appended) are usually placed in the file
<filename>/etc/modules.conf</filename>. [Note that in earlier Linux kernels
this file was often called <filename>/etc/conf.modules</filename>.]
For further information about the format of this file try
<command>man modules.conf</command>.
-->
<command>modprobe &lt;module_name></command> コマンドは、&lt;module_name> 
をロードする場合、同時に &lt;module_name> が依存しているモジュールすべてを
自動的にロードしようとします。
また、&lt;module_name> を指定する際、末尾の「.o」拡張子は不要です。
なければそのように想定されます。
【訳註：modprobe のモジュール名指定には、パス ('/') や末尾の '.o' を含めては
いけません。man modprobe してください】
<command>insmod &lt;module_name></command> も &lt;module_name> をロードしよう
としますが、そのモジュールが依存しているモジュールを先にロードしません。
モジュールをロードする規則、つまりあるモジュールがその他のモジュール
を(適切なパラメタをつけた上で)どのようにロードするのかは、通常 
<filename>/etc/modules.conf</filename> に記述してあります。(初期の Linux 
カーネルでは、このファイルを <filename>/etc/conf.modules</filename> と呼んで
いたことに注意)。
このファイルの形式についてのさらに詳しい情報については、
<command>man modules.conf</command> してみてください。

</para>
<para>
<!--
Any module can have its allowable command line parameters queried with
this command: <command>modinfo -p &lt;module_name></command>.
-->
どのモジュールにもコマンドラインで利用できるパラメタがあり、これは 
<command>modinfo -p &lt;module_name></command> コマンドを使って調べられます。
</para>
<para>
<!--
When upper level drivers are initialized and if there are no hosts active
then the mid level will attempt to load a module called "scsi_hostadapter".
An "alias" can then be used to associate "scsi_hostadapter" with the actual
name of the lower level (adapter) driver.
For example, a line like "alias scsi_hostadapter aic7xxx" in the
<filename>/etc/modules.conf</filename> file would cause the aic7xxx module
to be loaded (if there were no lower level drivers already active).
-->
高レベルのドライバが初期化され、アクティブなホストが存在しない場合は、
中間レベルが「scsi_hostadapter」というモジュールをロードしようとします。
ここで「alias」を使うと、「scsi_hostadapter」と実際の低レベル(アダプタ)
ドライバの名前とを結び付けられます。
例えば <filename>/etc/modules.conf</filename> に
「alias scsi_hostadapter aic7xxx」という行を置けば、aic7xxx モジュール
がロードされます(既にアクティブな低レベルのドライバがなければ)。
<footnote><para>
<!--
There is a sequencing issue here if the root file system is on the SCSI
device controlled by the lower level (adapter) driver to be loaded since
it contains the <filename>/etc/modules.conf</filename> file. Also there
is the issue of how the boot loader obtains the initial kernel image from 
a SCSI device (often from the (master) boot record). The latter is usually
taken care of by the system's or adapter card's BIOS.
-->
ルートファイルシステムが、SCSI デバイスにあり、それを制御する低レベルの
(アダプタ)ドライバが <filename>/etc/modules.conf</filename> に記述されて
いる場合、ロードする順序に関する問題が生じます。ブートローダーが 
SCSI デバイス(たいていは(マスター)ブートレコード)から、最初にカーネル
をどのように 持ってくるのか、という問題もあります。後者は通常システムの BIOS 
もしくはアダプタ・カードの BIOS が面倒をみています。

</para></footnote>
</para>
<para>
<!--
There is a special relationship between the module parameter
"scsi_hostadapter" and the initrd file system. For more information see
<command>man initrd</command> and <command>man mkinitrd</command>.
-->
モジュールのパラメタ(alias)である「scsi_hostadapter」と initrd ファイルシステム
には特別な関係があります。さらに詳しいことは、
<command>man initrd</command> と <command>man mkinitrd</command> 
してください。
<footnote><para>
<!--
An example of using <command>mkinitrd</command>: assume the root
partition is on a SCSI disk connected to a controller from 
Adaptec that requires the aic7xxx driver. After
building a kernel with the aic7xxx driver specified as a module then 
load the image into the normal place (probably in the
<filename>/boot</filename> directory). Next make sure a line like
"alias scsi_hostadapter aic7xxx" is in the <filename>/etc/modules.conf
</filename> file. Then from the <filename>/boot</filename> directory
execute a line like <command>mkinitrd /boot/initrd-2.4.5.img 2.4.5</command>
(this assumes lk 2.4.5 is being build). This should result in the
file <filename>initrd-2.4.5.img</filename> being created. The
<filename>/etc/lilo.conf</filename> should then have a section added
looking something like this:
-->
<command>mkinitrd</command> の使用例です。ルートパーティションが SCSI 
ディスク上にあり、これは Adaptec のコントローラ(aic7xxx ドライバが必要)に接続
されているとします。aic7xxx ドライバをモジュールとしてカーネルを構築した後、
カーネルイメージを通常の場所に置きます(おそらく <filename>/boot</filename> 
ディレクトリ)。次に「alias scsi_hostadapter aic7xxx」というような行が 
<filename>/etc/modules.conf</filename> ファイルにあることを確認します。
<filename>/boot</filename> ディレクトリから 
<command>mkinitrd /boot/initrd-2.4.5.img 2.4.5</command> のようなコマンド
ラインを実行してください(Linux カーネル 2.4.5 が構築してあると仮定)。
これで <filename>initrd-2.4.5.img</filename> が生成されるはずです。
<filename>/etc/lilo.conf</filename> には、下記のような項目を追加することに
なるでしょう。
<programlisting>
image=/boot/vmlinuz-2.4.5
    label=linux
    initrd=/boot/initrd-2.4.5.img
    read-only
    root=/dev/sda7
</programlisting>
<!--
The following should also be selected in the kernel configuration:
-->
カーネルの設定では次のような内容を選択しておく必要があります。
<programlisting>
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
</programlisting>
<!--
See also <filename>Documentation/initrd.txt</filename>.
-->
<filename>Documentation/initrd.txt</filename> も見てください。
</para></footnote>
</para>
</chapter>

<chapter id="procfs">
      <!--
  		<title>Proc pseudo file system</title>
  		-->
  		<title>Proc 擬似ファイルシステム</title>
<para>
<!--
The proc pseudo file system provides some useful information about the
SCSI subsystem. The kernel configuration option that selects "proc_fs" 
is CONFIG_PROC_FS and in almost all cases it should be selected. SCSI
specific information
is found under the directory <filename>/proc/scsi</filename>. Probably
the most commonly accessed entry is <command>cat /proc/scsi/scsi</command>
which lists the attached SCSI devices. See
<xref linkend="mlproc"/> for more details.
-->
proc 擬似ファイルシステムは、SCSI サブシステムについて役立つ情報を提供
します。「proc_fs」を選択するカーネルの設定オプションは、CONFIG_PROC_FS 
で、たいての場合は選択されているはずです。SCSI 固有の情報は、
<filename>/proc/scsi</filename> にあります。おそらく一番よくアクセスされる
項目は、接続している SCSI デバイスをリストアップする 
<command>cat /proc/scsi/scsi</command> です。詳細は <xref linkend="mlproc"/>
を見てください。
</para>
<para>
<!--
The lower level drivers are allocated proc_fs entries of the form:
-->
低レベルのドライバは、次の形で proc_fs に割り当てられています。
<programlisting>
    /proc/scsi/&lt;driver_name>/&lt;scsi_adapter_number>
</programlisting>
<!--
where the &lt;driver_name> is something like "aic7xxx" or "BusLogic". The
&lt;scsi_adapter_number> (also known as the host number) is the same number
that was discussed in <xref linkend="scsiaddr"/>. Note that one driver 
may control one or more hosts.
What is stored in this file is lower level driver dependent (and in the
case of some adapter drivers it
is possible to set parameters via this file). When reporting problems
to newsgroups or maintainers it is useful to include the output of this
file (e.g. <command>cat /proc/scsi/aic7xxx/0 </command>).
-->
&lt;driver_name> は「aic7xxx」や「BusLogic」などになります。
&lt;scsi_adapter_number>(ホスト番号とも呼ぶ)は、
<xref linkend="scsiaddr"/>で論じたものと同じ番号です。1 つのドライバが
複数のホストを制御する場合もあるので、注意してください。
このファイルに記録されている内容は、低レベルドライバによって変わります
(このファイルを通してパラメタを設定できるアダプタドライバもあります)。
ニュースグループやメンテナーに障害の報告をする際には、このファイルの出力を
添付すると役に立ちます(例えば <command>cat /proc/scsi/aic7xxx/0 </command>)。
</para>
<para>
<!--
The cdrom driver provides information about attached cdrom devices
in the <filename>/proc/sys/dev/cdrom</filename> directory. This will
include both SCSI devices (i.e. those controlled by the sr driver) and
IDE devices (i.e. those controlled by the ide-cd driver).
See <xref linkend="srproc"/>.
-->
CD-ROM ドライバは、接続している CD-ROM デバイスの情報を 
<filename>/proc/sys/dev/cdrom</filename> ディレクトリで提供しています。
ここには、SCSI デバイス(つまり sr ドライバが制御しているもの)と IDE デバイス
(つまり ide-cd ドライバが制御しているもの)が入っています。
<xref linkend="srproc"/>を見てください。
</para>
<para>
<!--
The sg driver provides information about its state and attached hosts and 
devices in the <filename>/proc/scsi/sg</filename> directory. 
See <xref linkend="sgproc"/>.
-->
sg ドライバは、ドライバの状態と接続されているホストおよびデバイスの情報を 
<filename>/proc/scsi/sg</filename> ディレクトリで提供しています。
</para>
<para>
<!--
More general information on the proc pseudo file system can be found in
the kernel source file: 
<filename>/usr/src/linux/Documentation/filesystems/proc.txt</filename>.
-->
proc 擬似ファイルシステムについてのより一般的な情報は、
カーネルソースのファイルである 
<filename>/usr/src/linux/Documentation/filesystems/proc.txt</filename> 
にあります。
</para>
</chapter>

<chapter id="mlevel">
      <!--
  		<title>Mid Level, Unifying layer</title>
  		-->
  		<title>中間レベル、統合レイヤ</title>
<para>
<!--
The SCSI mid level is common to all usage of the SCSI subsystem. Probably
its most important role is to define internal interfaces and services that
are used by all other SCSI drivers. These internal mechanisms are not
discussed in this document [see ref: <link linkend="W2">W2</link>].
-->
SCSI の中間レベルは、SCSI サブシステムを使う場合は必ず利用されます。
おそらく最も重要な機能は、その他すべての SCSI ドライバが使用する内部
インタフェースと内部サービスとを定義することです。これら内部のしくみについては、
このドキュメントでは論じません(<link linkend="W2">W2</link>を参照)。
</para>
<para>
<!--
The primary kernel configuration parameter "CONFIG_SCSI" determines whether
the mid level is built in (when "=y") or a module (when "=m"). If
"CONFIG_SCSI=m" then all other SCSI subsystem drivers must also be modules.
-->
大元のカーネル設定パラメタである「CONFIG_SCSI」によって、中間レベルが組み込み
か(=y)、モジュールなのか(=m)が決まります。「CONFIG_SCSI=m」なら、その他すべて
の SCSI サブシステムのドライバもモジュールになっていなければいけません。
</para>
<para>
<!--
When the mid level is built as a module then it probably never needs to be
loaded explicitly because using 'modprobe' to load any other SCSI subsystem
module will cause the mid level to be loaded first (if it is not already).
-->
中間レベルがモジュールとして構築されている場合、これをわざわざロードする必要は
まずありません。「modprobe」を使って他の SCSI サブシステムの モジュールを
ロードすれば、中間レベルが(既にロードされていなければ)ロードされるからです。
</para>
<para>
<!--
Some upper and lower level drivers do not (fully) load if there are no
devices for that driver to control. Sometimes the report is loud as in
this case for the imm driver which controls zip drives connected to a
parallel port:
-->
高レベルと低レベルのドライバには、そのドライバが制御するデバイスが 1 つ
もなければ、(完全には)ロードされないものもあります。時にはおおげさに報告
されるケースもあります。例えば次に示すように、パラレルポートに接続している 
zip ドライバを制御する imm ドライバがそうです。
<programlisting>
$ modprobe imm                                 
   imm.o: init_module: No such device
</programlisting>
<!--
<command>lsmod</command> will not show the "imm" module as loaded.
In other cases the result is more subtle. For example, if the sg driver
is loaded in a system with no (real or pseudo) scsi devices then the
<filename>/proc/scsi/sg</filename> directory will not appear. [It will
be created when the first scsi device is recognized.]
-->
<command>lsmod</command> は「imm」モジュールがロードされたとは表示しません。
もっと微妙な結果になる場合もあります。例えば sg ドライバ
がシステムにSCSI デバイスが(実際にあるものもしくは擬似にせよ)何もない状態で
ロードされると、<filename>/proc/scsi/sg</filename> ディレクトリは出現しません
(SCSI デバイスが認識されてはじめて作成されます)。
</para>

<sect1 id="mlbparams">
      <!--
  		<title>boot parameters</title>
  		-->
  		<title>ブート時のパラメタ</title>
<para>
<!--
SCSI drivers that are built into the kernel are checked in a pre-determined
order to see if HBAs that they can control are present. The user has no
control over this order which in most cases is
arbitrary but in the case of some older ISA adapters is required to stop
misidentification
-->
カーネルに組み込まれた SCSI ドライバは、あらかじめ決められた順番で、制御する 
HBA があるかどうか調べられます。
ユーザはこの順番を制御することは一切できません。
この順番はどうでも構わない場合がほとんどですが、古い ISA アダプタでは誤認識を
防ぐために調べるのを止めなければならないものもあります。
<footnote><para>
<!--
PCI adapters are much "safer" for initialization code than the older ISA
adapters. Hence the order of initialization of PCI adapters is unlikely
to lead to lockups. In this case the order of initialization (and thus
SCSI adapter numbers) of built in drivers may be modified by changing the
order of entries in the SCSI subsystem Makefile (<filename>
/usr/src/linux/drivers/scsi/Makefile</filename>). Beware: some adapters
may be recognized by more than one lower level driver (e.g. those
based on NCR chipsets).
-->
PCI アダプタは古い ISA アダプタに比べて、初期化コードが「より安全」です。
したがって、PCI アダプタの初期化過程で固まるようなことはほとんどありません。
この場合、組み込みドライバの初期化の順序(つまり、SCSI アダプタ番号)は、
SCSI サブシステムの Makefile
(<filename>/usr/src/linux/drivers/scsi/Makefile</filename>)にある項目の順序
を変更すれば修正できるかもしれません。(注意)複数のドライバが認識するドライバ
もあります(例えば NCR のチップベースのアダプタ)。
</para></footnote>
.
<programlisting>

<!--
scsi_logging=&lt;n>
    where &lt;n> is 0 to turn logging off
    where &lt;n> is non-zero to turn logging on

max_scsi_luns=&lt;n>
    where &lt;n> is a number between 1 and 8 (&lt; lk 2.4.7),
    	>= lk 2.4.7 the upper limit can be much larger
-->
scsi_logging=&lt;n>
    &lt;n> が 0 だとログは取らない。
    &lt;n> が 0 でなければログを取る。

max_scsi_luns=&lt;n>
    &lt;n> は 1 から 8 の値(&lt; lk 2.4.7)で、カーネル 2.4.7 以上は上限
    をさらに増やせる。

scsihosts=host0:hosts1::host3 
</programlisting>
</para>
<para>
<!--
The recently introduced devfs defines a "scsihosts"
boot time parameter to give the user some control over this. See the
devfs documentation [ref: <link linkend="W5">W5</link>] for a description.
The host names given in the list to the "scsihosts" boot option are
the names of lower level drivers (e.g. "scsihosts=advansys:imm::ide-scsi").
-->
最近公開された devfs では、「scsihosts」というブート時パラメタを定義しており、
ユーザがこの順序を制御できるようになっています。devfs のドキュメント
(<link linkend="W5">W5</link>を参照)の説明を見てください。
ブート時オプションの「scsihosts」に渡すリストに指定するホスト名は、
低レベルのドライバ名です(例えば「scsihosts=advansys:imm::ide-scsi」)。
<footnote>
<para>
<!--
Either comma or colon can be delimiters for "scsihosts". This means that
"scsihosts=advansys,imm,,ide-scsi" is also valid.
-->
「scsihosts」の区切り文字は、カンマもしくはコロンです。
つまり「scsihosts=advansys,imm,,ide-scsi」も有効です。
</para>
</footnote>
<footnote>
<para>
<!--
Using "scsihosts" can lead to a situation in which the computer's BIOS finds
the boot track (and hence boot time parameters set in lilo or grub) on one
disk while the kernel finds the root partition on another disk. This can
be quite confusing when it is unplanned. Hence after changing (or adding)
"scsihosts" in lilo or grub's configuration, it may be wise to boot the
machine to see which disks are accessed.
-->
「scsihosts」を使うと、コンピュータの BIOS はブートトラック(および lilo 
や grub で設定されたブート時設定)をどれかのディスクに見つけ、一方カーネルは
ルートパーティションを別のディスクで見つける、というような状況になることが
あります。
無計画に行ってしまうと、これはかなり混乱します。よって lilo や grub で
「scsihosts」の設定を変更(追加)した後は、マシンをブートし、どのディスクが
アクセスされるかを見るのが賢明です。
</para>
</footnote>
<!--
Devfs does not need to be present for "scsihosts" to be used. The
"scsihosts" parameter, if given, is echoed during in the boot up messages.
For example:
-->
「scsihosts」の利用に devfs は必要ありません。
「scsihosts」パラメタは、指定されればブート時のメッセージに出力されます。
例えば 
<programlisting>
scsi: host order: advansys:imm::ide-scsi
</programlisting>
<!--
Also if multiple HBA are present in a system then they are scanned in
a fixed order (see footnote). The "scsihosts" parameter only effects how
these HBAs are indexed (i.e. which SCSI adapter numbers are associated with
them by the kernel). In the above example, if the "imm" driver is not found
during boot up, then the scsi adapter number "1" is not allocated. If the
"imm" driver is later loaded as a module, then it will adopt scsi adapter
number "1". If a driver that is not named in "scsihosts" is found, then
it will get the next available scsi adapter number (e.g. a built in
aic7xxx driver would get scsi adapter number "2" in the above example).
-->
また、複数の HBA がシステムにあると、決まった順序でスキャンされます(補注
を参照)。「scsihosts」パラメタは、これらの HBA がどのように順序付けされるか 
(つまりカーネルがどの SCSI アダプタ番号とどの HBA を関係付けているか) 
だけに影響します。
上記の例では、「imm」ドライバがブート時に見つからなければ、SCSI アダプタ番号
「1」は割り当てられません。「imm」ドライバが後にモジュールとして ロードされる
と、それに SCSI アダプタ番号「1」が割り当てられます。
「scsihosts」に載っていないドライバが見つかると、次に利用可能な SCSI 
アダプタ番号が使用されます(例えば上記の例なら、組み込みの aic7xxx ドライバ
は、SCSI アダプタ番号の「2」になる)。
</para>
<para>
<!--
A full list of kernel parameters with some explanations can be found
in the file <filename>/usr/src/linux/Documentation/kernel-parameters.txt
</filename>.
-->
カーネルパラメタの全リストとその説明は、
<filename>/usr/src/linux/Documentation/kernel-parameters.txt</filename> 
ファイルにあります。
</para>
</sect1>

<sect1 id="mlmparams">
      <!--
  		<title>module parameters</title>
  		-->
  		<title>モジュールのパラメタ</title>
<para>
<!--
If SCSI disks are present in the system then it usually is better to
build the mid level driver into the kernel. However if the SCSI
subsystem is only being used periodically (e.g. to burn CD-Rs on
an ATAPI CD writer) then building the mid level as a module is fine.
The module load time options are the same as the driver's built in
options:
-->
システムに SCSI ディスクがある場合、通常は中間レベルのドライバをカーネルに 
組み込む方が望ましいでしょう。SCSI サブシステムを時折使うだけなら(例えば 
ATAPI CD ライターで CD-R を焼く)、中間レベルをモジュールとして構築した方が
良いと思います。
モジュールロード時のオプションは、組み込みのものと同じです。
<programlisting>
<!--
scsi_logging_level=&lt;n>
    where &lt;n> is the logging level mask (0 for logging off)
max_scsi_luns=&lt;n>
scsihosts=host0::host2
-->
scsi_logging_level=&lt;n>
    &lt;n> はロギングレベルのマスク(0 がロギングしない)
max_scsi_luns=&lt;n>
scsihosts=host0::host2
</programlisting>
</para>
</sect1>

<sect1 id="mlproc">
  		<!--
      <title>proc interface</title>
  		-->
      <title>proc インタフェース</title>
<para>
<!--
To display the SCSI devices currently attached (and recognized) by the SCSI
subsystem use <command>cat /proc/scsi/scsi</command>.
-->
現在 SCSI サブシステムに接続している(認識されている) SCSI デバイスを
表示するには、<command>cat /proc/scsi/scsi</command> としてください。
</para>
<para>
<!--
The output looks like this:
-->
出力は下記のようになります。
<programlisting>
    Attached devices:
    Host: scsi0 Channel: 00 Id: 02 Lun: 00
      Vendor: PIONEER  Model: DVD-ROM DVD-303  Rev: 1.10
      Type:   CD-ROM              ANSI SCSI revision: 02
    Host: scsi1 Channel: 00 Id: 00 Lun: 00
      Vendor: IBM      Model: DNES-309170W     Rev: SA30
      Type:   Direct-Access       ANSI SCSI revision: 03
</programlisting>
</para>
<para>
<!--
After the "Attached devices:" line there are 3 lines for each recognized
device. The first of these lines is SCSI address information discussed in
<xref linkend="scsiaddr"/>. The following 2 lines of data are
obtained from a INQUIRY
command that was performed on the device when it was attached. See
<xref linkend="sg"/> for the relationship between the ordering of these
devices compared with the sg driver's ordering (which most of the time is
the same).
-->
「Attached devices:」行に続き、認識されているデバイスそれぞれについて、3 行
ずつが表示されます。これらのうちの最初の行は、<xref linkend="scsiaddr"/>で
論じた SCSI アドレスの情報です。
あとの 2 行は、デバイスの接続時に実行された INQUIRY コマンドから得たデータ
です。これらのデバイスの順序と sg ドライバでの順序との関係については、
<xref linkend="sg"/>を見てください(たいていの場合は同じ)。
</para>
<para>
<!--
Existing devices can be removed using <command>
  echo "scsi remove-single-device &lt;h> &lt;b> &lt;t &lt;l>"
                      > /proc/scsi/scsi</command>
where the variables are host, bus (channel), target (scsi id) and lun. The
success (or otherwise) of this command can be determined by sending a
subsequent <command>cat /proc/scsi/scsi</command> command. The removal
will fail if the
device is busy (e.g. if a file system on the device is mounted).
-->
既存のデバイスは、<command>
  echo "scsi remove-single-device &lt;h> &lt;b> &lt;t> &lt;l>"
                      > /proc/scsi/scsi</command>
を使って削除できます。引数は、ホストとバス(チャネル)、ターゲット(SCSI ID)、
LUN です。このコマンドが成功したかどうかは、そのコマンドの後に 
<command>cat /proc/scsi/scsi</command> を実行すればわかります。デバイス
が busy だと(例えばデバイスがファイルシステムにマウントされていれば)削除は
失敗するでしょう。
</para>
<para>
<!--
New devices can be added using <command>
    echo "scsi add-single-device &lt;h> &lt;b> &lt;t> &lt;l>"
                      > /proc/scsi/scsi</command>
where the variables are host, bus (channel), target (scsi id) and lun. The
success (or otherwise) of this command can be determined by sending a
subsequent <command>cat /proc/scsi/scsi</command> command.
-->
新規のデバイスは、<command>
    echo "scsi add-single-device &lt;h> &lt;b> &lt;t> &lt;l>"
                      > /proc/scsi/scsi</command>
を使って追加できます。引数は、ホストとバス(チャネル)、ターゲット(SCSI ID)、
LUN です。このコマンドが成功したかどうかは、そのコマンドの後に 
<command>cat /proc/scsi/scsi</command> を実行すればわかります。
<footnote><para>
<!--
The parsing of "add-single-device" and "remove-single-device" is rather
inflexible. Hence it is best to stay close to the demonstrated syntax
with no extra spaces (and no tabs).
-->
「add-single-device」と「remove-single-device」でのパーズは融通が利き
ません。
よって余分な空白(やタブ)を入れず、例で挙げた書き方そのままにするように
してください。
</para></footnote>
</para>
<para>
<!--
The SCSI subsystem does not support hot-plugging of SCSI devices (there may
also be electrical issues on the associated SCSI parallel bus). It is 
recommended that those who use add+remove-single-device make sure that
other devices on that SCSI bus are inactive if re-plugging is going to
take place.
-->
SCSI サブシステムは、SCSI デバイスのホットプラグをサポートしていません
(SCSI パラレルバスに関連した電気的な問題もある)。
add+remove-single-device して、接続し直そうとする場合は、その SCSI バス上の
他のデバイスも間違いなく停止させてください。
</para>
<para>
<!--
To output a list of internal SCSI command blocks use <command>
    echo "scsi dump &lt;n>" > /proc/scsi/scsi</command>
where the numeric value of &lt;n> doesn't matter. This is probably only of
interest to people chasing down bugs within the SCSI subsystem.
-->
内部 SCSI コマンドをまとめてリスト出力するには、<command>
    echo "scsi dump &lt;n>" > /proc/scsi/scsi</command>
を使ってください。&lt;n> の数値は何でもかまいません。数値に興味を持つのは、
恐らく SCSI サブシステム内部のバグを追跡する方だけでしょう。
</para>
<para>
<!--
To start (or stop) logging information being sent to the console/log use
-->
ロギング情報をコンソールやログに出したり止めたりするには、
<command>
    echo "scsi log &lt;token> &lt;n>" > /proc/scsi/scsi
</command>
を使用してください。
<!--
where &lt;token> is one of: {all, none, error, timeout, scan, mlqueue,
mlcomplete, llqueue, llcomplete, hlqueue, hlcomplete, ioctl}
and &lt;n> is a number between 0 and 7. The tokens "all" and "none" don't
take an &lt;n> argument. Prefix meanings:
-->
&lt;token> には、「all、none、error、timeout、scan、mlqueue、mlcomplete、
llqueue、llcomplete、hlqueue、hlcomplete、ioctl」のどれか 1 つを指定します。
&lt;n> は、0 から 7 の数字です。「all」と「none」は、&lt;n> 引数
をとりません。接頭辞の意味は下記の通りです。
<programlisting>
  	<!--
    hl    upper level drivers [exception: sg uses "timeout"]
    ml    mid level
    ll    lower level drivers
           [adapter drivers often have there own flags]
  	-->
    hl    高レベルのドライバ(例外：sg は「timeout」を使う]
    ml    中間レベル 
    ll    低レベルのドライバ
          (アダプタドライバには独自のフラグがあることがよくある)
</programlisting>
<!--
The value "0" turns off logging while "7" maximizes the volume of output.
Logging information will only be output if CONFIG_SCSI_LOGGING was selected
in the kernel build.
-->
「0」という値はロギングを無効にし、「7」は出力をできるだけ詳細にします。
ロギング情報は、カーネル構築の際に CONFIG_SCSI_LOGGING を選択した場合のみ
出力されます。
</para>
<warning>
<para>
<!--
Warning: "scsi log all" (and several other variants) can cause a logging
infinite loop if the log file (typically <filename>/var/log/messages
</filename>) lies on a SCSI disk. Either turn off the kernel logging
daemon or direct its output to a non SCSI device.
-->
警告：「scsi log all」(および同様の他の指定)とすると、ログファイル 
(たいてい <filename>/var/log/messages</filename>)が SCSI ディスクにある 
場合、ログの無限ループを引き起こすかもしれません。カーネルのロギングデーモン
を無効にするか、出力を SCSI デバイスではないデバイスへ向けてください。
</para>
</warning>
</sect1>
</chapter>

<chapter id="ulevel">
      <!--
  		<title>Upper level drivers</title>
  		-->
  		<title>高レベルのドライバ</title>
<para>
<!--
The upper level drivers maintain the kernel side of the OS interface
for the logical class of devices they represent (e.g. disks). They
are also responsible for managing certain kernel and SCSI subsystem
resources such as kernel memory and SCSI command structures.
Applications in the user space access these drivers by opening a special
file (block or char) typically found in the <filename>/dev
</filename> directory tree.
-->
高レベルのドライバは、デバイスの論理クラス(例えばディスク)において、OS 
インタフェースのカーネル側を管理します。また高レベルのドライバは、
カーネルメモリや SCSI コマンド構造といった、カーネルや SCSI サブシステム
のリソース管理も担当しています。
ユーザ空間で動くアプリケーションは、スペシャルファイル(ブロックもしくは
キャラクタ)をオープンし、これらのドライバにアクセスします。このスペシャル
ファイルは、通常 <filename>/dev</filename> ディレクトリツリーにあります。
</para>

<sect1 id="sd">
      <!--
  		<title>Disk driver (sd)</title>
  		-->
  		<title>ディスクドライバ(sd)</title>
<para>
<!--
Two types of SCSI devices are accessible via the sd driver:
-->
sd ドライバを経由してアクセスできる SCSI デバイスは、2 種類あります。
<itemizedlist>
<!--
<listitem><para>"direct access" devices which are usually magnetic disks.
[SCSI peripheral device code is 0]</para></listitem>
<listitem><para>"Optical memory devices" which are often called MOD
disks. [SCSI peripheral device code is 7]</para></listitem>
-->
<listitem><para>「直接アクセス」デバイス。通常は磁気ディスクを指す。
(SCSI 周辺装置コードは 0)</para></listitem>
<listitem><para>「光メモリデバイス」。MOD ディスクと呼ばれることが多い。
(SCSI 周辺装置コードは 7)</para></listitem>
</itemizedlist>
<!--
The sd driver is a block device which means that it is closely associated
with the block subsystem. It also supports the concept of partitions.
[<command>man sd</command> dates from 1992.]
-->
sd ドライバはブロックデバイスで、密接にブロックサブシステムと結びついて
います。パーティションの概念もサポートしています
(<command>man sd</command>は 1992 年から存在します)。
</para>
<para>
<!--
The sd driver is capable of recognizing 128 disks when it is loaded
at kernel boot time or later as a module. However, once it is loaded,
it will only recognize a fixed number of additional disks. The number
of additional disks that can be accommodated is set by the kernel
configuration parameter CONFIG_SD_EXTRA_DEVS whose default value is 40.
-->
sd ドライバは、カーネルのブート時、もしくはブートした後にモジュールとして
ロードされた時に、128 個のディスクを認識できます。しかし一度ロードされると、
増設分のディスクは一定個数のみ認識されます。この増設ディスクの個数は、カーネル
設定パラメタである CONFIG_SD_EXTRA_DEVS によって設定します。デフォルトの値は 
40 です。
</para>

<sect2 id="sdbparams">
      <!--
  		<title>sd boot parameters</title>
  		-->
  		<title>sd のブート時のパラメタ</title>
<para>
<!--
None.
-->
ありません。
</para>
</sect2>

<sect2 id="sdmparams">
      <!--
  		<title>sd module parameters</title>
  		-->
  		<title>sd モジュールのパラメタ</title>
<para>
<!--
The sd driver takes no parameters when loaded as a module. Note that
its module name is <filename>sd_mod.o</filename>.
-->
sd ドライバは、モジュールとしてロードされた場合、何もパラメタをとりません。
モジュール名は <filename>sd_mod.o</filename> であることをお忘れなく。
</para>
</sect2>
</sect1>

<sect1 id="sr">
  		<!--
      <title>CDROM driver (sr or scd)</title>
  		-->
      <title>CDROM ドライバ(sr もしくは scd)</title>
<para>
<!--
CDROM and DVD drives (and WORM devices) are accessible via the sr upper 
level device driver.
While "sr" is the device driver name, "sr_mod" is its module name.
The device file name is either <filename>/dev/sr&lt;n></filename> or
<filename>/dev/scd&lt;n></filename>.
-->
CD-ROM と DVD ドライブ(と WORM デバイス)は、高レベルのデバイスドライバで
ある sr 経由でアクセスできます。
デバイスドライバの名前は「sr」ですが、モジュール名は「sr_mod」です。
デバイスファイル名は <filename>/dev/sr&lt;n></filename> もしくは
<filename>/dev/scd&lt;n></filename> です。
</para>
<para>
<!--
Following is a diagram illustrating the CDROM subsystem of which sr is a
part:
-->
下記の図表は、sr を含む CD-ROM サブシステムの説明です。
</para>

    <mediaobject>
      <imageobject>
        <imagedata fileref="cdrom.eps" format="EPS"/>
      </imageobject>
      <imageobject>
        <imagedata fileref="cdrom.jpg" format="JPG"/>
      </imageobject>
      <caption><para>
      <!--
  		The architecture of the CD-ROM subsystem.
  		-->
  		CD-ROM サブシステムの構造
      </para></caption>
    </mediaobject>

<para>
<!--
This diagram glosses over some of the differences between the 
protocol stacks. CDROM device names are <emphasis>not</emphasis> maintained
by the uniform CDROM layer but rather by each individual protocol stack.
In the case of the SCSI subsystem, device names are maintained by the
sr driver while the IDE subsystem maintains device names with its
central "ide" driver (i.e. not by the ide-cd driver). USB and IEEE1394
cd devices names are maintained by their respective stacks. This may
partially explain why the <filename>/dev/cdrom</filename> is often a
symbolic link to the appropriate subsystem's device name.
-->
この図表では、プロトコルスタック間の違いは隠れています。CD-ROM デバイス名
は CD-ROM レイヤが統一して面倒を見ているわけでは<emphasis>なく</emphasis>、
むしろ個々のプロトコルスタックが面倒を見ています。
IDE サブシステムでは、中心にある「ide」ドライバがデバイス名の面倒を見ている
(つまり、ide-cd ドライバではない)のに対し、SCSI サブシステムでは sr ドライバ
が行っています。USB や IEEE1394 の cd デバイス名は、
おのおののスタックが面倒を見ています。これは、<filename>/dev/cdrom</filename> 
が適切なサブシステムのデバイス名へのシンボリック・リンクになっている理由の
一部と言えるかもしれません。
</para>
<para>
<!--
Two types of SCSI devices are accessible via the sr driver:
-->
sr ドライバ経由でアクセスできる SCSI デバイスには、2 つのタイプがあります。
<itemizedlist>
<!--
<listitem><para>CD-ROM devices (including DVD players)
[SCSI peripheral device code is 5]</para></listitem>
<listitem><para>"Write-once read-multiple" devices which are known as WORMs.
[SCSI peripheral device code is 4]</para></listitem>
-->
<listitem><para>CD-ROM デバイス(DVD プレイヤーを含む)
(SCSI 周辺機器コードは 5)</para></listitem>
<listitem><para>WORM と呼ばれる「追記型」デバイス
(SCSI 周辺機器コードは 4)</para></listitem>
</itemizedlist>
</para>
<para>
<!--
The sr driver is capable of recognizing 256 CDROM/DVD drives when it is 
loaded at kernel boot time or later as a module. However, once it is 
loaded, it will only recognize a fixed number of additional drives. The 
number of additional drives that can be accommodated is set by the kernel
configuration parameter CONFIG_SR_EXTRA_DEVS whose default value is 2.
-->
sr ドライバは、カーネルのブート時、もしくはモジュールとしてブート後にロード
された時に、256 個の CD-ROM もしくは DVD を認識できます。しかし、一度ロード
されると、増設分のドライブは一定個数のみ認識します。この増設ドライブの個数は、
カーネル設定パラメタである CONFIG_SR_EXTRA_DEVS で設定します。デフォルトの値
は 2 です。
</para>

<sect2 id="srbparams">
  		<!--
      <title>sr boot parameters</title>
  		-->
      <title>sr のブート時のパラメタ</title>
<para>
<!--
None.
-->
ありません。
</para>
</sect2>

<sect2 id="srmparams">
  		<!--
      <title>sr module parameters</title>
  		-->
      <title>sr モジュールのパラメタ</title>
<para>
<!--
Doing a test to find out if a cdrom drive supports XA mode (mode 2) triggers
firmware bugs on some drives. Consequently the check for XA mode support is
turned off by default. The following module parameter is provided:
-->
CD-ROM ドライブが XA モード(モード 2)をサポートしているかどうかを調べる
テストを行うと、ドライブによってはファームウェアのバグを招く場合があります。
そのため XA モードのサポートのチェックは、デフォルトで無効になっています。
次のようなモジュールパラメタがあります。
<programlisting>
    xa_test=&lt;0|1>
</programlisting>
<!--
to override the default. [Currently there seems to be no way to turn on
XA mode testing when the sr driver is built into the kernel.]
-->
デフォルトを変更します。(sr ドライバがカーネルに組み込まれていると、現状では 
XA モードのテストを有効にする方法が無いようです)。
</para>
</sect2>
<sect2 id="srproc">
  		<!--
      <title>sr proc interface</title>
  		-->
      <title>sr proc インタフェース</title>
<para>
<!--
All the following files are readable by all and produce ASCII output
when read:
-->
下記のファイルは誰も読め、ASCII で出力されます。
<programlisting>
 /proc/sys/dev/cdrom/autoclose
 /proc/sys/dev/cdrom/autoeject
 /proc/sys/dev/cdrom/check_media
 /proc/sys/dev/cdrom/debug
 /proc/sys/dev/cdrom/info
 /proc/sys/dev/cdrom/lock
</programlisting>
<!--
They reflect the current state of the CDROM subsystem. This location
is part of the procfs's window through to the sysctl configuration
mechanism (see <command>man sysctl</command>). All but
<filename>info</filename> are writable by the superuser. There is
a column for each CDROM and DVD player in the system in
<filename>info</filename> (not just SCSI devices). 
-->
これらのファイルは、CD-ROM サブシステムの現在の状態を表わしています。
これらは procfs 領域の一部で、sysctl の設定機構に通じています
(<command>man sysctl</command> を参照)。<filename>info</filename> 以外は、
スーパーユーザが書き込めます。<filename>info</filename> には、
システムにある CD-ROM と DVD プレーヤーそれぞれの列が存在しています
(SCSI デバイス以外も含む)。
</para>
<para>
<!--
As an
example, the auto eject feature can be turned on by the superuser with
the command <command>echo "1" > /proc/sys/dev/cdrom/autoeject</command>.
This will cause cdroms to be ejected from the drive when unmounted.
-->
例として、スーパーユーザが
<command>echo "1" > /proc/sys/dev/cdrom/autoeject</command> 
とすると、オートエジェクト機能が有効になります。
こうするとアンマウント時にドライブから CD-ROM がイジェクトします。
</para>
</sect2>
<sect2 id="sratapi">
  		<!--
      <title>ATAPI cdroms</title>
  		-->
      <title>ATAPI CD-ROM</title>
<para>
<!--
Many Linux users have no SCSI devices (or adapters) in their systems. They
become a little perplexed as to why cd writer software (e.g. 
<command>cdrecord</command> and <command>cdrdao</command>)
and cd music reading programs (e.g. <command>cdparanoia</command>) use
the Linux SCSI subsystem. The answer is that these programs need lower level
access to these devices. ATAPI (ATA Packet Interface) is essentially
a SCSI command set sent over an ATA 
-->
Linux ユーザの多くは、SCSI デバイス(もしくはアダプタ)を持っていません。
そのようなユーザは、CD ライターのソフトウェア(例えば 
<command>cdrecord</command> や <command>cdrdao</command>))や音楽 CD を聞く
プログラム(例えば <command>cdparanoia</command>)が、なぜ Linux の SCSI 
サブシステムを使用するのか、少々戸惑います。答えは、それらのプログラムが
デバイスへアクセスするのに、低レベルのドライバを必要としているからです。
ATAPI(ATA Packet Interface)は、基本的に ATA 転送越しにSCSI コマンドセットを
送り出しています
<footnote><para>
<!--
ATA is the modern name for what was previously known as IDE and/or EIDE.
Note that the subsystem that controls ATA devices in Linux is called
the "IDE" subsystem for historical reasons.
-->
ATA は最近の呼び名で、以前は IDE もしくは EIDE と言っていました。
Linux では、これまでの経緯から ATA デバイスを制御するサブシステムを「IDE」
サブシステムと呼んでいる点に注意してください。
</para></footnote>
<!--
transport. [The discussion in this section is also applicable to ATAPI
tape drives and ATAPI floppy drives.]
-->
(このセクションでの議論は、ATAPI テープドライブと ATAPI フロッピードライブ
にも適用できます)。
</para>
<para>
<!--
Currently both <command>cdrecord</command> and <command>cdparanoia</command>
interface to the SCSI generic driver (sg) and, in the case of ATAPI 
cd devices, use the ide-scsi pseudo device driver to access the hardware.
This may change in the future as in the 2.4 series kernels a packet
interface ioctl has been added to the uniform cdrom layer (see the diagram
in <xref linkend="sr"/> above).
-->
現状 <command>cdrecord</command> と <command>cdparanoia</command> は
ともに SCSI 汎用ドライバ(sg) と接続しています。また ATAPI CD デバイス
の場合は、ハードウェアにアクセスするのに ide-scsi 擬似デバイスを利用して
います。
カーネル 2.4 系列で ioctl のパケットインタフェースが、統合 CD-ROM レイヤに
追加されたので(上記の <xref linkend="sr"/> の図を参照)これは今後変更される
かもしれません。
<footnote><para>
<!--
Other ATA devices such as tapes and floppies often use the ATAPI interface. 
However, the vast majority of ATA disks do <emphasis>not</emphasis> use
the ATAPI interface.
-->
テープやフロッピーのような他の ATA デバイスは、たいてい ATAPI インタフェース
を使っています。
しかし、圧倒的多数の ATA ディスクは、ATAPI インタフェースを<emphasis>
使っていません</emphasis>。
</para></footnote>
</para>
<para>
<!--
The default action of the IDE subsystem in Linux is to claim all ATA
devices for its built-in drivers. In the case of an ATAPI cd writer, it 
will be claimed by the built-in ide-cd driver. Once this has happened, 
the SCSI subsystem is unable to get control over an ATAPI device. The 
ide-scsi (pseudo lower level SCSI) driver can only register ATAPI devices 
in the SCSI subsystem that have <emphasis>not</emphasis> already been 
claimed by the IDE subsystem.
-->
Linux の IDE サブシステムのデフォルト動作は、組み込みのドライバが
すべての ATA デバイスの管理権限を要求します 。
ATAPI CD ライターなら、組み込みの ide-cd ドライバが要求を出します。
一度こうなると、SCSI サブシステムは ATAPI デバイスの制御ができなくなります。
ide-scsi(擬似低レベル SCSI)ドライバは、IDE サブシステムによって要求され
<emphasis>なかった</emphasis> ATAPI デバイスだけを SCSI サブシステムに登録
できます。
</para>
<para>
<!--
Notice the <emphasis>built-in</emphasis> qualification in the previous 
paragraph. If both the ide-cd and ide-scsi drivers are modules then the 
first one loaded will claim the ATAPI cd devices (e.g. cd/dvd readers and 
writers). Furthermore you can switch the controlling driver module by 
<command>rmmod</command>-ing one and <command>modprobe</command>-ing the 
other.
-->
前段落の<emphasis>組み込み</emphasis>という条件に注意してください。
ide-cd と ide-scsi ドライバがモジュールなら、最初にロードされたものが ATAPI 
CD デバイス(例えば CD-ROM もしくは DVD の リーダーやライター)を要求します。
さらに、ドライバモジュールを <command>rmmod</command> したり、他のモジュール
を <command>modprobe</command> したりして、制御を切り替えられます。
</para>
<para>
<!--
Probably the most flexible way to instruct the IDE core driver that you
want the cd writer at <filename>/dev/hdd</filename> accessible to
<command>cdrecord</command> is to use the kernel boot option: 
"hdd=ide-scsi". This will cause the ide-cd driver to bypass 
<filename>/dev/hdd</filename> (irrespective of whether ide-cd driver is 
built-in or a module). As long as the ide-scsi driver is built-in or a 
module then it will "capture" the cd writer
at <filename>/dev/hdd</filename> (with the IDE core driver loading the
ide-scsi module if required).
-->
<filename>/dev/hdd</filename>にある CD ライターを
<command>cdrecord</command>からアクセス可能とするよう IDE のコアドライバに
対して命令するには、カーネルブート時のオプションである「hdd=ide-scsi」を
利用する方法が最も柔軟でしょう。これで ide-cd ドライバは
<filename>/dev/hdd</filename> を無視します(ide-cd ドライバが組み込みで
あってもモジュールであっても関係ありません)。ide-scsi ドライバが組み込み
もしくはモジュールとして存在すれば、<filename>/dev/hdd</filename> にある CD 
ライターを「横取り」します(要求されると、IDE のコアとなるドライバは ide-scsi 
モジュールをロードします)。
</para>
<para>
<!--
The ide-cd driver module can be instructed to ignore certain ATA devices
with the following syntax:
-->
ide-cd ドライバモジュールには、特定の ATA デバイスを無視するよう、次のように
命令できます。
<programlisting>
modprobe ide-cd ignore='hdc hdd'
</programlisting>
<!--
In this case the ide-cd driver will ignore the devices at 
<filename>/dev/hdc</filename> and <filename>/dev/hdd</filename> .
This effect can also be accomplished by placing a line like this: 
"options ide-cd ignore=hdd" in the <filename>/etc/modules.conf</filename> 
file.
-->
この場合、ide-cd ドライバは <filename>/dev/hdc</filename> と 
<filename>/dev/hdd</filename> にあるデバイスを無視します。
<filename>/etc/modules.conf</filename> ファイルに「options ide-cd ignore=hdd」
という行を追加することによって同じ効果が得られます。
</para>
<para>
<!--
A new option added in the lk 2.4 series is of the form "hdd=scsi".
This option seems to have a similar function to the "hdd=ide-scsi"
option discussed above. Furthermore "hdd=scsi" can only be used if
both the SCSI mid-level and the ide-scsi drivers are built into the
kernel (otherwise "BAD OPTION" is reported by the ide_setup function).
-->
カーネル 2.4 系列に追加された新しいオプションに「hdd=scsi」があります。
このオプションは、上記で述べた「hdd=ide-scsi」と同じような機能に見えます。
さらに「hdd=scsi」は、SCSI 中間レベルと ide-scsi ドライバが両者とも
カーネルに組み込まれた時にだけ利用できます(これ以外の場合には ide_setup 
関数が「BAD OPTION」を報告します)。
</para>
<para>
<!--
To find out whether an ATAPI cd device is "owned" by the SCSI subsystem, 
the output of <command>cat /proc/scsi/scsi</command> can be checked. 
Another technique is to observe the "drive name:" line of
<command>cat /proc/sys/dev/cdrom/info</command> for "sr" entries. The
following output is from my system:
-->
SCSI サブシステムが ATAPI CD デバイスを「管理」しているかどうかを見る
には、<command>cat /proc/scsi/scsi</command> の出力をチェックしてください。
もう 1 つの方法は、<command>cat /proc/sys/dev/cdrom/info</command> の
「drive name:」を見て、「sr」という項目に注目する方法です。下記は私の
システムの出力です。
<programlisting>
$ cat /proc/sys/dev/cdrom/info 
CD-ROM information, Id: cdrom.c 3.12 2000/10/18

drive name:             sr1     sr0
drive speed:            16      0
drive # of slots:       1       1
Can close tray:         1       1
Can open tray:          1       1
Can lock tray:          1       1
Can change speed:       1       1
Can select disk:        0       0
Can read multisession:  1       1
Can read MCN:           1       1
Reports media changed:  1       1
Can play audio:         1       1
Can write CD-R:         1       0
Can write CD-RW:        1       0
Can read DVD:           0       1
Can write DVD-R:        0       0
Can write DVD-RAM:      0       0
</programlisting>
</para>
<para>
<!--
Once an ATAPI cd writer at /dev/hdd has been registered by the SCSI
subsystem, then cdroms should be mounted via the "scd" device name
and cd players should also use the "scd" device. Strangely the
<command>hdparm</command> command should still use the <filename>
/dev/hdd</filename> device file (or the "echo ... > /proc/ide/hdd/settings"
method).
-->
/dev/hdd にある ATAPI CD ライターが 一度でも SCSI サブシステムへ登録されると、
CD-ROM は「scd」というデバイス名を使ってマウントされるはずです。CD プレーヤー
も「scd」デバイスを使わなければいけません。妙なことに、
<command>hdparm</command> コマンドは、まだ <filename>/dev/hdd</filename> 
デバイスファイルを使用することになっています
(もしくは、「echo ... > /proc/ide/hdd/settings」という方法で)。
<footnote><para>
<!--
In the linux 2.4 kernel series there has been an increase in problems when
the ide-scsi driver is used so that <command>cdrecord</command> can control
ATAPI (IDE) cd writers. The problem may be related to the aggressive manner 
in which the IDE subsystem attempts to optimize the speed of data transfers 
on devices it controls. Some people experiencing timeouts and machine lockups 
have found that reducing the DMA setting via the <command>hdparm</command>
command has fixed the problem. If the cd writer is connected to 
<filename>/dev/hdd</filename> then users have reported success with one of
these two commands: 
-->
Linux カーネル 2.4 系列では、ide-scsi ドライバを用いて
<command>cdrecord</command> が ATAPI(IDE) CD ライターを制御できるようにした
場合に、問題が生じることが多くなっています。
この問題は、IDE サブシステムが制御下のデバイスに対して、無茶なやり方でデータ
転送速度を最適化しようとする点に関連しているようです。タイムアウトが発生
したりマシンが固まったりする現象を経験した人の中には、
<command>hdparm</command> コマンドを使って DMA の設定を遅くすることで
問題を解決できた方もいるようです。CD ライターが <filename>/dev/hdd</filename> 
に接続されていれば、下記の 2 つのコマンドのどちらかで、うまくいったことが
わかります。
<programlisting>
    hdparm -d0 -c1 /dev/hdd 
    hdparm -d 1 -X 34 /dev/hdd 
</programlisting>
<!--
The first one turns off DMA completely while the second one sets it in
"multiword DMA mode 2". Cd writers do not need the types of speeds that 
modern disks utilize. Even burning at "x16" implies a sustained transfer 
rate of 16 times 150 KB/sec which is approximately 2.4 MB/sec, not
really that fast. There has also been a report that moving a cd writer off
a high speed IDE controller (Promise) and back to the motherboard's lower 
speed IDE controllers has fixed a random IDE bus reset problem. Another 
report suggests reducing (or turning off) the DMA on the IDE hard disk can 
also stop lockups.
-->
最初のものは DMA を完全に無効化し、次のものは「マルチワード DMA モード 2」
にします。CD ライターは、最近ディスクが使用するようなタイプの速度を必要として
いません。「16倍速」で焼いたとしても、維持する転送速度は 150 KB/sec の
16 倍、これはほぼ 2.4MB/sec に当たります。これは高速とは言えません。
また、高速な IDE コントローラ(Promise 製)から CD ライターを外し、
マザーボードの低速な IDE コントローラに接続し直すと、不規則に発生する 
IDE バスのリセット問題が解決した、という報告もあります。別の報告では、IDE 
ハードディスクの DMA を低速にする(もしくは無効にする)と固まることが
なくなった、とあります。
</para></footnote>
</para>
</sect2>
</sect1>

<sect1 id="st">
      <!--
  		<title>Tape driver (st)</title>
  		-->
  		<title>テープドライバ(st)</title>
<para>
<!--
The tape driver interface is documented in the file
<filename>/usr/src/linux/drivers/scsi/README.st</filename> and on the
st(4) man page (type <command>man st</command>). The file
<filename>README.st</filename> also documents the different parameters and
options of the driver together with the basic mechanisms used in the driver.
-->
テープドライバのインタフェースについては、
<filename>/usr/src/linux/drivers/scsi/README.st</filename> ファイルか、
st(4) の man ページ(<command>man st</command>と入力)にまとめられています。
<filename>README.st</filename> には、様々なドライバの様々なパラメタや
オプション、ドライバが使っている基本的なしくみも記述してあります。
</para>
<para>
<!--
The tape driver is usually accessed via the <command>mt</command> command
(see <command>man mt</command>). <command>mtx</command> is an associated
program for controlling tape autoloaders
(see <ulink url="http://mtx.sourceforge.net">
<literal>mtx.sourceforge.net</literal></ulink>).
-->
テープドライバは、通常 <command>mt</command> コマンド(<command>man mt
</command>を参照)でアクセスします。<command>mtx</command> は、テープオート
ローダーの制御に対応しているプログラムです
(<ulink url="http://mtx.sourceforge.net">
<literal>mtx.sourceforge.net</literal></ulink>を参照)。
</para>
<para>
<!--
The st driver detects those SCSI devices whose peripheral device type
is "Sequential-access" (code number 1) unless they appear on the
driver's "reject_list". [Currently the OnStream tape drives (described
in a following section) are the only entry in this reject_list.]
-->
st ドライバは、周辺機器タイプが「シーケンシャルアクセス」(コード番号が 1)で
ある SCSI デバイスを検出します(ドライバが「reject_list」にあるものは除く)。
(現状 reject_list にある項目は OnStream のテープドライブ[次のセクションで
説明]だけです)。
</para>
<para>
<!--
The st driver is capable of recognizing 32 tape drives. There are
8 device file names for each tape drive: a rewind and non-rewind
variant for each of 4 modes (numbered 0 to 3). See the tape device
file name examples in <xref linkend="dnames"/> on device names. Any number of
tape drives (up to the overall limit of 32) can be added after the st
driver is loaded.
-->
st ドライバは 32 台のテープドライブを認識できます。テープドライブ
それぞれに 8 つのデバイスファイル名があります。4 つのモード(番号は 0 から 3 
まで)それぞれに、リワインドあり、リワインドなしのバリエーションがあります。
テープデバイスのファイル名は、<xref linkend="dnames"/>に例があるので見て
ください。テープドライブは st ドライバのロード後にいくつでも追加できます
(限度の 32 個まで)。
</para>
<para>
<!--
ATAPI tape drives can be controlled by this driver with help from the
ide-scsi pseudo adapter driver. The discussion in <xref linkend="sratapi"/> 
also applies for ATAPI tape drives (and ATAPI floppies).
-->
このドライバは、ide-scsi 擬似アダプタのドライバをともに用いれば、ATAPI 
テープドライブを制御できます。<xref linkend="sratapi"/>で論じたことは、
ATAPI テープデバイス(と ATAPI フロッピー)にも当てはまります。
</para>

<sect2 id="stbparams">
  		<!--
      <title>st boot parameters</title>
  		-->
      <title>st のブート時のパラメタ</title>
<para>
<programlisting>
<!--
st=xxx[,yyy] where xxx is one of the following:
-->
st=xxx[,yyy] の xxx は下記の内の 1 つを取ります。
buffer_kbs:&lt;n>
write_threshold_kbs:&lt;n>
max_buffers:&lt;n>
max_sg_segs:&lt;n>

<!--
(The old boot parameters st=aa[,bb[,cc[,dd]]] supported but deprecated)
-->
(以前のブート時のパラメタである st=aa[,bb[,cc[,dd]]] もサポートされていますが、
推奨されません)
</programlisting>
</para>
<para>
<!--
The default driver buffer size (buffer_kbs) is 32 (i.e. 32 KB).
The default asynchronous write threshold (write_threshold_kbs) is 30 
(i.e. 30 KB).
The default number of buffers allocated at initialization (max_buffers)
is 4.
The default number of scatter/gather segments to use (max_sg_segs) is
32.
-->
デフォルトのドライバのバッファサイズ(buffer_kbs)は 32(つまり 32 KB)です。
デフォルトの非同期書き込み閾値は 30(つまり 30 KB)です。
デフォルトで初期化時に確保するバッファの数(max_buffers)は 4 です。
デフォルトで使用する scatter/gather セグメントの数(max_sg_segs)は 32 です。
</para>
<para>
【訳註：Scatter/Gather(スキャッタ・ギャザー) とは、DMA、バス・マスター等、
高速な転送を行う場合に、分散してしまっているメモリ上のデータをまとめて
連続転送する機能です】
</para>
</sect2>

<sect2 id="stmparams">
      <!--
  		<title>st module parameters</title>
  		-->
  		<title>st のモジュールのパラメタ</title>
<para>
<programlisting>
buffer_kbs=&lt;n>
write_threshold_kbs=&lt;n>
max_buffers=&lt;n>
max_sg_segs=&lt;n>
</programlisting>
</para>
</sect2>

<sect2 id="stproc">
      <!--
  		<title>st proc interface</title>
  		-->
  		<title>st の proc インタフェース</title>
<para>
<!--
None.
-->
ありません。
</para>
</sect2>
<sect2 id="stosst">
      <!--
  		<title>osst driver for OnStream devices</title>
  		-->
  		<title>OnStream デバイス用 osst ドライバ</title>
<para>
<!--
There is an auxiliary tape driver for tape drives manufactured by
OnStream. It is an additional upper level driver and can co-exist with
the st driver. Its driver name is "osst" (as is its module name).
-->
OnStream が製造したテープドライブには、別のドライブがあります。
付加的な高レベルのドライバで、st ドライバと共存できます。このドライバ
は「osst」です(モジュール名も同じ)。
</para>
<para>
<!--
The OnStream SC-x0 SCSI tape drives can not be driven by the 
standard st driver, but instead need this special osst driver and 
use the <filename>/dev/osst&lt;x></filename> char device nodes (major 206).   
[Where &lt;x> follows the same naming scheme as st devices outlined
in <xref linkend="dnames"/>.]
Via usb-storage and ide-scsi, you may be able to drive the USB-x0 
and DI-x0 drives as well. Note that there is also a second generation
of OnStream tape drives (ADR-x0) that supports the standard SCSI-2
commands for tapes (QIC-157) and can be driven by the standard 
driver st. For more information, you may have a look at the kernel
source file <filename>/usr/src/linux/drivers/scsi/README.osst</filename>.
More info on the OnStream driver may be found on 
<ulink url="http://linux1.onstream.nl/test/">
<literal>linux1.onstream.nl/test/</literal></ulink>.
-->
OnStream の SC-x0 SCSI テープドライブは、標準の st ドライバでは動作
しません。そのかわりに、特別な osst ドライバと 
<filename>/dev/osst&lt;x></filename> キャラクタデバイスノード(メジャー
番号 206)が必要になります。
(&lt;x> は <xref linkend="dnames"/> にあるような、st デバイスと
同様な命名規則に従います)。
usb-storage と ide-scsi を用いれば、USB-x0 と DI-x0 ドライブが動作するかも
しれません。OnStream には、第二世代のテープドライブ(ADR-x0)が存在することに
注意してください。これは、テープ(QIC-157)用の標準 SCSI-2 コマンドをサポート
しており、st の標準ドライバで動作します。さらに詳しい情報は、カーネルソース
のファイルである 
<filename>/usr/src/linux/drivers/scsi/README.osst</filename> を見てください。
OnStream ドライバ情報をさらに知りたければ、
<ulink url="http://linux1.onstream.nl/test/">
<literal>linux1.onstream.nl/test/</literal></ulink>にあります。
</para>
</sect2>
</sect1>

<sect1 id="sg">
  		<!--
      <title>Generic driver (sg)</title>
  		-->
      <title>汎用ドライバ(sg)</title>
<para>
<!--
All types of SCSI devices are accessible via the sg driver. This means
devices such as CDROM drives can be accessed both via the sr and sg
drivers. Other SCSI devices such as scanners can only be accessed
via the sg driver.
The sg driver is capable of recognizing 256 SCSI devices. Any number of
devices (up to the overall limit of 256) can be added after the sg
driver is loaded.
-->
あらゆる種類の SCSI デバイスは、sg ドライバ経由でアクセスできます。つまり、
CD-ROM ドライブなら、sr と sg ドライバいずれでもアクセスできます。スキャナー
のようなその他の SCSI デバイスは sg ドライバを使ってのみアクセスできます。
sg ドライバは、256 個の SCSI デバイスを認識できます。デバイスは sg ドライバ
のロード後にいくつでも追加できます(ただし限度の 256 まで)。
</para>
<para>
<!--
See reference <link linkend="W4">W4</link> for the SCSI Generic (sg) driver
documentation (also found there is the sg_utils package). 
For SCSI standards see reference <link linkend="W1">W1</link> and for a
book on the subject of SCSI programming and pass through mechanisms see
reference <link linkend="B3">B3</link>.
-->
SCSI 汎用(sg)ドライバのドキュメントは<link linkend="W4">W4</link>を参照
してください(sg_utils パッケージにも入っています)。
SCSI 規格については、<link linkend="W1">W1</link>や SCSI のプログラミングが
主題となっている書籍を参照してください。しくみを勉強したければ、
<link linkend="B3">B3</link>を参照してください。
</para>
<para>
<!--
The sg driver in lk 2.4 is "version 3" which adds an additional interface
structure and some new ioctl()s. The most interesting new ioctl()
is SG_IO which sends a SCSI command and waits for its response. 
See the Linux Documentation Project site:
<ulink url="http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/">
<literal>www.tldp.org/HOWTO/SCSI-Generic-HOWTO/</literal></ulink> 
for a full description of the sg driver.
A (possibly later) version of this document can be found at
<ulink url="http://www.torque.net/sg/p/sg_v3_ho.html">
<literal>www.torque.net/sg/p/sg_v3_ho.html</literal></ulink>.
-->
カーネル 2.4 における sg ドライバは「バージョン 3」で、インタフェース機構の
追加と新しい ioctl() が加わりました。新規の ioctl() で一番おもしろいのは、
SG_IO で、SCSI コマンドを送り出し、その応答を待ちます。
Linux Documentation Project サイトにある 
<ulink url="http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/">
<literal>www.tldp.org/HOWTO/SCSI-Generic-HOWTO/</literal></ulink> 
には、sg ドライバについての完璧な解説があります。
このドキュメントの(おそらくより新しい)バージョンは、
<ulink url="http://www.torque.net/sg/p/sg_v3_ho.html">
<literal>www.torque.net/sg/p/sg_v3_ho.html</literal></ulink>にあります。
</para>
<para>
<!--
The abbreviation "sg" is used within the kernel to refer both to the
SCSI generic driver and the scatter-gather capability offered by many
modern IO devices (usually associated with DMA). The context usually
makes it clear which one is being referred to. As an example, note the
contorted sg ioctl() named SG_GET_SG_TABLESIZE where the second "SG"
refers to scatter gather.
-->
カーネル内で使用されている「sg」という略語には、SCSI 汎用ドライバを指す場合
と、最近の入出力デバイス(普通は DMA 対応)の多くが提供している、scatter-gather 
機能を指す場合に使われています。どちらを意味するのかは、文脈次第です。
例えば、SG_GET_SG_TABLESIZE という分りにくい sg の ioctl()は、2 番目の
「SG」が scatter-gather を指しています。
</para>
<para>
<!--
The public interface for sg is found in the file: <filename>
/usr/src/linux/include/scsi/sg.h</filename>. Depending on the distribution
this may or may not contain the same information as <filename>
/usr/include/scsi/sg.h</filename> which is controlled by the GNU library
maintainers. If these 2 files are not the same use the former header
file. Those writing applications based on sg should see its documentation
for more on this matter.
-->
sg の公開インタフェースは <filename>/usr/src/linux/include/scsi/sg.h
</filename> にあります。ディストリビューションにもよりますが、これは 
GNU ライブラリのメンテナーが管理している 
<filename>/usr/include/scsi/sg.h</filename> と同じ内容かもしれませんし、違う
かもしれません。この 2 つのファイルの内容が同じでなければ、前者のヘッダー
ファイルを使ってください。
sg ベースでアプリケーションを書く場合は、sg の文書を見て、この問題をより
深く理解する方が良いでしょう。
</para>
<para>
<!--
The sg driver registers all SCSI devices (with a current maximum of 256)
as they are seen. Each newly registered SCSI device gets allocated the
next available minor device number. At least initially this will be the
same sequence that devices are displayed in mid level's <command>
cat /proc/scsi/scsi</command>. The sg devices device mapping can be
seen with <command>cat /proc/scsi/sg/devices</command> or <command>
cat /proc/scsi/sg/device_strs</command>. Differences between
<command>cat /proc/scsi/scsi</command> and sg orderings will appear when
a low level driver is removed (e.g. <command>rmmod aha1542</command>) or
when a device is removed with remove-single-device.
The sg driver will leave remaining SCSI device mapping to minor device
numbers unchanged. This potentially leaves a "hole" in the sg mapping.
An example follows:
-->
sg ドライバは、現在ある SCSI デバイスすべてを登録しています(現状の最大数は、
256 個)。新しく登録する SCSI デバイスそれぞれに、次に利用可能なマイナー番号
が確保されます。少なくとも最初の内は、<command>cat /proc/scsi/scsi
</command>で表示される中間レベルのものと同じ順番です。sg デバイスの
マッピングは、<command>cat /proc/scsi/sg/devices</command> もしくは 
<command>cat /proc/scsi/sg/device_strs</command> でわかります。
<command>cat /proc/scsi/scsi</command> と sg の順序の違いが生じるのは、
低レベルのドライバが削除された時(例えば <command>rmmod aha1542</command>)や
デバイスが remove-single-device で削除された時です。
sg ドライバは、残っている SCSI デバイスを変更すること無く、マイナー
デバイス番号にマッピングし続けます。これは sg のマッピングに「欠番」を
残すことになります。
下記がその例です。
<programlisting>
$ cat /proc/scsi/scsi 
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: DNES-309170W     Rev: SA30
  Type:   Direct-Access            ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 02 Lun: 00
  Vendor: PIONEER  Model: DVD-ROM DVD-303  Rev: 1.10
  Type:   CD-ROM                   ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 00
  Vendor: YAMAHA   Model: CRW4416S         Rev: 1.0g
  Type:   CD-ROM                   ANSI SCSI revision: 02

$ cat /proc/scsi/sg/device_strs 
IBM             DNES-309170W            SA30
PIONEER         DVD-ROM DVD-303         1.10
YAMAHA          CRW4416S                1.0g

$ echo "scsi remove-single-device 1 0 2 0" > /proc/scsi/scsi

$ cat /proc/scsi/scsi 
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: DNES-309170W     Rev: SA30
  Type:   Direct-Access            ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 06 Lun: 00
  Vendor: YAMAHA   Model: CRW4416S         Rev: 1.0g
  Type:   CD-ROM                   ANSI SCSI revision: 02

$ cat /proc/scsi/sg/device_strs 
IBM             DNES-309170W            SA30
&lt;no active device>
YAMAHA          CRW4416S                1.0g
</programlisting>
<!--
Notice how the sg driver maintains the row positions of the remaining
devices in the "device_strs" output. So when the Pioneer
dvd player is removed, a hole opens up in the sg device mapping
which is not reflected in the <command>cat /proc/scsi/scsi</command>
output. That "hole" corresponds to the device name <filename>
/dev/sg1</filename>.
-->
sg ドライバが「device_strs」の出力において、残っているデバイスの並び位置を
どのように管理しているかをよく見てください。Pioneer の DVD プレーヤーが削除
されると sg デバイスのマッピングには欠番ができますが、
<command>cat /proc/scsi/scsi</command> には現れません。この「欠番」は
<filename>/dev/sg1</filename> に該当します。
</para>
<para>
<!--
The new sg_io_hdr interface includes a data transfer residual count
field called "resid". Only some lower level adapters support this
feature and those that don't always yield zero in this field. At
the time of writing the advansys, aha152x and the sym53c8xx
drivers support this feature.
-->
新しい sg_io_hdr インタフェースには、未転送データ量をカウントするための
「resid」というフィールドがあります。低レベルのアダプタのいくつかだけが
この機能をサポートしており、その場合でのみこのフィールドに 0 以外が入ります。
このドキュメントの執筆時では、advansys、aha152x、sym53c8xx ドライバがこの機能
をサポートしています。
</para>

<sect2 id="sgbparams">
  		<!--
      <title>sg boot parameters</title>
  		-->
      <title>sg のブート時のパラメタ</title>
<para>
<!--
The sg driver maintains a reserved buffer for each open file descriptor.
The purpose is to guarantee applications that data transfers up to the
size of the reserved buffer will not fail for lack of kernel memory. This
is important for applications like cdrecord that cannot easily recover
(the CDR) from a ENOMEM error.
-->
sg ドライバは、オープンしているファイルディスクリプタそれぞれに対して、
予約済みのバッファを管理しています。
この目的は、アプリケーションのデータ転送に際してカーネルのメモリが足りなく
なっても、予約バッファの大きさに達するまでは転送が失敗しないことを保証する
ことです。
これは、cdrecord のような ENOMEM エラーから簡単には復旧できない(CD-R なので)
アプリケーションにとっては重要です。
</para>
<para>
<!--
In the absence of the boot parameter 'sg_def_reserved_size' or the sg module
parameter 'def_reserved_size', then each time a sg file descriptor is opened
the reserved buffer size is inherited from SG_DEF_RESERVED_SIZE which is
defined in <filename>include/linux/sg.h</filename>.
-->
ブート時のパラメタに「sg_def_reserved_size」がなかったり、sg モジュールの
パラメタである「def_reserved_size」がなかったりすると、sg のファイル
ディスクリプタがオープンする度に、<filename>include/linux/sg.h</filename> 
に定義してある SG_DEF_RESERVED_SIZE をそのまま使います。
</para>
<para>
<!--
The SG_DEF_RESERVED_SIZE define value can be overridden by this kernel boot
option:
-->
SG_DEF_RESERVED_SIZE の値は、下記のカーネルブート時のオプションで変更可能
です。
<programlisting>
    sg_def_reserved_size=&lt;n>
</programlisting>
</para>
</sect2>

<sect2 id="sgmparams">
  		<!--
      <title>sg module parameters</title>
  		-->
      <title>sg のモジュールのパラメタ</title>
<para>
<!--
When the sg module is loaded the SG_DEF_RESERVED_SIZE define value can be
overridden by supplying this option:
-->
sg モジュールがロードされる時、SG_DEF_RESERVED_SIZE で定義してある値は下記
のオプションで変更できます。
<programlisting>
    def_reserved_size=&lt;n>
</programlisting>
</para>
</sect2>

<sect2 id="sgproc">
  		<!--
      <title>sg proc interface</title>
  		-->
      <title>sg の proc インタフェース</title>
<para>
<!--
All the following files are readable by all and produce ASCII output
when read. The file
'def_reserved_size' is also writable by root. The ASCII output has been
formatted in such a way as to be human and machine readable (and hence
a compromise). Use Unix commands of the form <command>cat device_hdrs devices
</command> to see the output of tables.
-->
次のファイルは誰もがすべて読み出し可能で、ASCII 形式で出力されます。
「def_reserved_size」は root が書き込み可能です。ASCII 出力は、人間と
マシン両者が読める形式になっています(そのため読みやすさは犠牲に
なっています)。表出力を見るには、
<command>cat device_hdrs devices</command> という Unix コマンドを使って
ください。
<programlisting>

<!--
/proc/scsi/sg/debug       [internal state of sg driver]
/proc/scsi/sg/def_reserved_size
                          [like boot/module load parameter]
/proc/scsi/sg/devices     [table of numeric device data]
/proc/scsi/sg/device_hdr  [column headers for sg/devices]
/proc/scsi/sg/device_strs [table of strings from INQUIRY]
/proc/scsi/sg/hosts       [table of numeric host data]
/proc/scsi/sg/host_hdr    [column headers for sg/hosts]
/proc/scsi/sg/host_strs   [table of string ids for hosts]
/proc/scsi/sg/version     [sg version number and date]
-->
/proc/scsi/sg/debug       [sg ドライバの内部状態]
/proc/scsi/sg/def_reserved_size
                          [ブート時もしくはモジュールをロードした時の
  												パラメタと同じ]
/proc/scsi/sg/devices     [数字表現のデバイスのデータテーブル]
/proc/scsi/sg/device_hdr  [sg と デバイスのカラムヘッダー]
/proc/scsi/sg/device_strs [INQUIRY からの文字列のテーブル]
/proc/scsi/sg/hosts       [ホストデータ(数字)のテーブル]
/proc/scsi/sg/host_hdr    [sg と ホストのカラムヘッダー]
/proc/scsi/sg/host_strs   [ホスト ID(文字列)のテーブル]
/proc/scsi/sg/version     [sg のバージョン番号と日付]
</programlisting>
<!--
All the above files are owned by root and readable by all while
<filename>def_reserved_size</filename> is writable by root. For the
<filename>devices</filename> and <filename>device_strs</filename> files
the first row output corresponds to <filename>/dev/sg0</filename>
(sg minor device number 0). The second row output corresponds to
<filename>/dev/sg1</filename>, etc.
For the <filename>hosts</filename> and <filename>host_strs</filename>
files the first row output corresponds to host (adapter number) 0, etc.
For numeric tables a missing device or host is indicated by a row
of "-1" values. For string tables a missing device or host is indicated
by a row containing "&lt;no active device/host>".
-->
上記のファイルすべては root がオーナーになっていて、どのユーザも読み込み可能
です。
<filename>def_reserved_size</filename> は root が書き込み可能です。
<filename>devices</filename> と <filename>device_strs</filename> 各ファイル
は、最初の列が <filename>/dev/sg0</filename> に対応しており(sg のマイナー
デバイス番号 0)、2 番目の列は <filename>/dev/sg1</filename> に対応しています
(以下同様)。
<filename>hosts</filename> と <filename>host_strs</filename> 各ファイルは、
最初の列がホスト(アダプタ番号)の 0 に対応しています(以下同様)。
数字で書いてあるテーブルでは、見つからないデバイスやホストはその列に「-1」
という値が表示されます。文字列で書いてあるテーブルでは、見つからない
デバイスもしくはホストはその列に「&lt;no active device/host」と表示されます。
</para>
</sect2>
</sect1>
</chapter>

<chapter id="llevel">
  		<!--
      <title>Lower Level drivers</title>
  		-->
      <title>低レベルのドライバ</title>
<para>
<!--
There are too many SCSI low level drivers to detail in this document.
As an alternative to giving any superficial overview here, the reader is 
given suggestions of places to look for further information.
-->
低レベルの SCSI ドライバは、あまりにたくさんあるので、このドキュメントでは
詳しく説明しません。
かわりに、ここではさわりをざっと見ていき、読者の方がさらに情報を見つけられる
ようにアドバイスします。
</para>
<para>
<!--
The source directory for the SCSI subsystem in the Linux kernel is a good place
to start: <filename>/usr/src/linux/drivers/scsi</filename>. Several drivers
have information in a "readme" file: <filename>README.&lt;driver_name>
</filename>. Others have extensive information at the top of their ".c" file
This information often includes a version number, change logs and kernel
boot time and module load
time options. Often the latter information can be found in the installation
guides of the various Linux distributions. Sometimes the driver maintainer will
have a web site containing the most recent bug fix information. Official
maintainers are listed in the <filename>/usr/src/linux/MAINTAINERS</filename>
file. If there is nothing there, look in the relevant ".c" file in the SCSI
subsystem directory. Some old drivers have no active maintainers. In such cases
posting to the linux-scsi newsgroup may help [see <link linkend="N1">N1
</link>].
-->
Linux カーネルの SCSI サブシステムのソースディレクトリ、
<filename>/usr/src/linux/drivers/scsi</filename> は出発点として適しています。
いくつかのドライバでは、<filename>README.&lt;driver_name></filename>という
「readme」ファイルに情報があります。その他のドライバも、各「.c」ファイル
の先頭にたくさんの情報が書かれています。
この情報として、バージョン番号、変更履歴、カーネルブート時やモジュール
ロード時のオプションなどが含まれる場合がよくあります。オプションに関する情報
は、様々な Linux ディストリビューションのインストールガイドにもあります。
ドライバのメンテナーが、Web サイトを立ち上げていて、そこに最新のバグフィックス
情報があるケースもあります。オフィシャルなメンテナーの方々は、
<filename>/usr/src/linux/MAINTAINERS</filename> ファイルに列挙してあります。
そこに挙がっていなければ、SCSI サブシステムのディレクトリにある、
該当する「.c」ファイルを見てください。古いドライバの中には、アクティブな
メンテナーがいないものもあります。そのような場合は、linux-scsi ニュース
グループに投稿すれば、助けてもらえるかもしれません
(<link linkend="N1">N1</link>を参照)。
</para>
<para>
<!--
For an overview of the drivers supplied with the kernel source tree,
use one of the kernel configuration programs (e.g. 
<command>cd /usr/src/linux; make menuconfig</command>). The help
information associated with each selection can be found together in one
(large) flat file at 
<filename>/usr/src/linux/Documentation/Configure.help</filename>.
Drivers can be obtained from other places. It is unlikely that a SCSI
driver made for the lk 2.2 series (or before) will build or operate
successfully in the lk 2.4 series. [From a programmatic viewpoint
there are not a lot of things that need changing.] Drivers may even
be only available in binary form, in which case make sure that you
trust the provider and follow their instructions closely.
-->
カーネルのソースツリーが提供するドライバの全体像を掴むには、カーネルの設定
プログラム(例えば <command>cd /usr/src/linux; make menuconfig</command>)
のどれかを利用してください。それぞれのセクションに対応したヘルプ情報は、
1 つの(巨大な)ファイル、
<filename>/usr/src/linux/Documentation/Configure.help</filename> にあります。
ドライバは他の所からも取得できます。カーネル 2.2 系(もしくはそれ以前)
用に作成したドライバは、カーネル 2.4系では構築や動作ができる可能性はわずかです。
(プログラムの面からは、変更が必要なところは多いとはいえません)。ドライバに
はバイナリ形式だけが利用可能なものもあるでしょう。この場合、提供者を信用
して、しっかり指示に従ってください。
</para>
<para>
<!--
Lower level drivers can support either of 2 error handling strategies.
The older one is considered obsolete while the newer one is often called
"new_eh". The advantage of "new_eh" is that it uses a separate kernel
thread per host (named "scsi_eh_&lt;n>" where &lt;n> is the host number) to 
facilitate error recovery. Both error handling strategies were also
available in the lk 2.2 series in which very few adapter drivers used
"new_eh". In the lk 2.4 series, more 
drivers are using it and the plan for the forthcoming lk 2.5 development
series is to drop mid level support for the older, obsolete error strategy.
-->
低レベルのドライバは、2 種類あるエラー処理のどちらかをサポートできます。
古い方法は時代遅れとみなされており、新しい方法は「new_eh」と呼ばれています。
「new_eh」の長所は、独立したカーネルスレッドをホスト(「scsi_eh_&lt;n>」と
いう名前が付きます。&lt;n> はホスト番号)単位で使用し、
エラーからの復旧機能を持たせている点にあります。どちらのエラー回復の方法も
カーネル 2.2 系で利用可能でしたが、アダプタドライバで「new_eh」を使って
いるものはほとんどありません。カーネル 2.4 系では、より多くのドライバが 
new_eh を使用しており、来たるカーネル 2.5 開発版では、旧式のエラー回復方法の
中間レベルにおけるサポートは打ち切りになります。
</para>
<para>
<!--
Drew Eckhardt's SCSI-HOWTO document [see reference <link linkend="W7">W7
</link>] goes into much more detail about lower level (adapter) drivers
than this document. Since that SCSI-HOWTO is 5 years old, many things
have changed and more drivers have been added.
-->
Drew Eckhardt 氏の SCSI-HOWTO ドキュメント(<link linkend="W7">W7</link>
を参照)では、低レベルの(アダプタの)ドライバについて、このドキュメント
よりもさらに詳細に踏み込んでいます。ただ SCSI-HOWTO は、5 年も前のもの
なので、その後の変更も多く、ドライバもさらに増えています。
</para>
<para>
<!--
There is a lower level driver called <emphasis>scsi_debug</emphasis>
that simulates one or more "direct access" devices (i.e. disk(s)) using 
the computer's memory. From lk 2.4.17 it acts as a "ram disk". While there
are many ram disk implementations available in Linux (e.g. ramfs), 
scsi_debug may help to isolate a defective scsi driver in a problematic 
installation. See <filename>scsi_debug.c</filename> for further information.
-->
<emphasis>scsi_debug</emphasis>という低レベルのドライバがあります。この
ドライバは、コンピュータのメモリを利用して、複数の「direct access」デバイス
(例えばディスク)をシミュレートします。カーネル 2.4.17 からは、
「ram disk」として動作します。Linux には色々な ram disk の実装がありますが
(例えば ramfs)、scsi_debug は、設定上の問題で障害がある SCSI ドライバを
切り分けするのに役立つでしょう。<filename>scsi_debug.c</filename> にさらに
情報があります。
</para>

<sect1 id="llevelpseudo">
  		<!--
      <title>Pseudo drivers</title>
  		-->
      <title>擬似ドライバ</title>
<para>
<!--
SCSI can be viewed as a command set and a set of hardware buses that convey
that command set. Those hardware buses can be further divided into those
used exclusively for SCSI (e.g. ultra wide), those shared with other
protocols (e.g. USB, IEEE 1394) and those buses not defined by the various
SCSI standards. In the final category there are several interesting examples
including ATAPI CD writers and PC parallel bus ZIP drives. Such devices
use the SCSI command set (or something very close to it) over a foreign bus.
-->
SCSI はコマンドの集まりと、そのコマンドの集まりを伝達するハードウェア
バスの集まりとみなすことができます。これらのハードウェアバスは専用の SCSI
(例えば ultra wide 用)として使われるもの、他のプロトコル(例えば USB や IEEE 
1394)と共用されるもの、種々の SCSI 規格では定義されていないもの等に分けられ
ます。最後のカテゴリには、ATAPI CD ライター、PC パラレルバス ZIP ドライブ
などの興味深い例があります。
このようなデバイスは、SCSI ではないバスで SCSI コマンドセット(もしくは非常に
近いもの)を利用します。
</para>
<para>
<!--
This section briefly outlines various pseudo lower level drivers which essentially
communicate with other Linux subsystems in order to send the SCSI command set
to devices controlled by those other subsystems. This raises some ownership
issues that often confuse users and result in many questions to the
maintainers.
-->
このセクションでは、様々な擬似低レベルドライバをざっと見ていきます。
これらは、他の Linux サブシステムが制御しているデバイスに対して SCSI コマンド
セットを送るため、必然的にそのサブシステムとやり取りすることになります。
この事が、主導権をどちらが握るのかという問題を引き起こす場合があり、これが
ユーザを混乱させ、結果的にメンテナーに数多くの質問が来ることになっています。
</para>
<formalpara><title>IDE-SCSI</title>

<para>
<!--
From configuration point of view, ide-scsi will grab and try to control
every ATA (a.k.a. IDE) device which doesn't have a "native"
driver attached (such as ide-cd, ide-tape, etc). So for example, if
both ide-cd and ide-scsi are compiled into the kernel in a system
which has an ATAPI cdrom, ide-cd will get to control it. If only
ide-scsi is compiled in, it will get the device. There are some
kernel boot time parameters to control which driver gets which device.
-->
設定の点からすると、ide-scsi は、「ネイティブの」ドライバ(ide-cd や 
ide-tape 等)が割り当てられていない ATA(別称 IDE)デバイスのすべてを取り込み、
制御しようとします。例えば ide-cd と ide-scsi 両方がカーネルに組み込まれて
コンパイルしてあり、そのシステムに ATAPI CD-ROM があれば、ide-cd が制御を握る
でしょう。ide-scsi だけが組み込まれていると、ide-scsi がそのデバイスを握り
ます。カーネルブート時に、どのドライバがどのデバイスを制御するのか指定する
パラメタもいくつかあります。
</para>
</formalpara>
<para>
<!--
The preferences of the IDE subsystem can be overridden with one of these
kernel boot time parameters (of which the first is most interesting for 
this subsystem):
-->
IDE サブシステムの選び方は、下記のカーネルブート時パラメタで上書き
可能です(このサブシステムにとって、最初のものが最も重要でしょう)。
<itemizedlist>
<listitem><para>
hdx=ide-scsi
</para></listitem>
<listitem><para>
hdx=ide-cdrom
</para></listitem>
<listitem><para>
hdx=ide-floppy
</para></listitem>
</itemizedlist>
<!--
[The term <emphasis>hdx</emphasis> is used
to refer to one of the IDE/ATA devices in {hda, hdb, hdc ...}.]
In the 2.4 series "hdx=scsi" was added but it is not very useful, see
see <xref linkend="sratapi"/>.
-->
(<emphasis>hdx</emphasis> という項目は、hda、hdb、hdc といった 
IDE(もしくは ATA)デバイスの 1 つを指します)。
2.4 系では「hdx=scsi」が追加されていますが、それほど便利ではありません。
<xref linkend="sratapi"/>を参照してください。
</para>
<para>
<!--
When the driver is running, the device will be accessible using
the SCSI device (<filename>/dev/sda</filename>, <filename>/dev/sr0
</filename>, etc), and not through the corresponding <filename>
/dev/hdx</filename> device. Still, the <filename>/dev/hdx
</filename> device will be available, but only for configuration.
-->
ドライバが動いていると、デバイスは SCSI デバイス
(<filename>/dev/sda</filename> や <filename>/dev/sr0</filename> 等)を使って
アクセスでき、そのデバイスに対応する <filename>/dev/hdx</filename> を使って
はアクセスできません。
その場合でも 
<filename>/dev/hdx</filename> デバイスは利用可能ですが、設定用のみです。
</para>
<para>
<!--
All the generic IDE configuration parameters (DMA on/off, 32-bit
I/O, unmasking irq's, etc) are available by using the <filename>
/dev/hdx</filename> device, for example to enable DMA:
-->
一般的な IDE の設定パラメタ(DMA の有効・無効、32 ビット I/O、unmasking IRQ 等)
はすべて、<filename>/dev/hdx</filename> デバイスが使えます。
例えば DMA を有効にするには下記のようにします。
<footnote><para>
<!--
It has been reported that in some distributions the attempt
to use the hdparm command fails. In this case use the "echo ... >
/proc/ide/hdx/settings" form.
-->
ディストリビューションによっては、hdparm コマンドが失敗するという報告が
挙がっています。そのような場合は "echo ... > /proc/ide/hdx/settings" 方式
を使ってください。
</para></footnote>
<programlisting>
        hdparm -d1 /dev/hdx
</programlisting>
<!--
Using <command>cat /proc/ide/hdx/settings</command> will show the
available settings.
All the generic IDE driver settings will be available there, as well
as the following "ide-scsi specific" settings:
-->
<command>cat /proc/ide/hdx/settings</command> とすると、指定できる設定を表示
します。
汎用 IDE ドライバの設定すべてが使えます。下記の「ide-scsi 固有の」設定も使え
ます。
<itemizedlist>
<listitem><para>bios_cyl</para></listitem>
<listitem><para>bios_head</para></listitem>
<listitem><para>bios_sect</para></listitem>
<listitem><para>transform</para></listitem>
<listitem><para>log</para></listitem>
</itemizedlist>
<!--
The first three choose the virtual geometry that the drive will
return to the sd driver, in case it's a disk drive (ZIP, etc).
"transform" will configure/enable/disable the SCSI to ATAPI CDB
transformation layer:
-->
ディスクドライブ(ZIP 等)の場合、はじめの 3 つはドライブが sd ドライバに
返す仮想ジオメトリを表しています。
「transform」は SCSI から ATAPI CDB へ変換するレイヤを設定したり、
有効にしたり、無効にしたりします。
【訳註：CDB とは、Command Descriptor Block の略称で、SCSI 命令のデータ
構造を指します】
<itemizedlist>
<!--
<listitem><para>bit 0: Enable(1)/Disable(0) transformation for
 commands not originated from the sg driver.</para></listitem>
<listitem><para>bit 1: Enable/Disable transformation for commands
 issued using the sg driver.</para></listitem>
-->
<listitem><para>0 ビット目: sg ドライバから発生していないコマンドの変換の
有効(1)もしくは無効(0)。</para></listitem>
<listitem><para>1 ビット目: sg ドライブを使って発行したコマンドの変換の有効
もしくは無効。</para></listitem>
</itemizedlist>
<!--
"log" will log debugging information. This is useful also to debug
user-space programs using the sg driver, as it will list the CDB
traffic on the bus &#045;&#045; each issued command, along with its completion
status.
To enable/disable a specific settings, use something like:
-->
「log」は、デバッグ情報を記録します。sg ドライバを使ったユーザ空間の
プログラムをデバックするのにも役立ちます。というのも、発行されたコマンドに
対してはその終了状態も含めてリストするからです。
特定の設定を有効にしたり、無効にしたりするには、下記のようにします。
<programlisting>
        echo "log:1" > /proc/ide/hdx/settings
</programlisting>
<!--
To turn off the "using_dma" flag use:
-->
「using_dma」フラグを無効にするには、下記のようにします。
<programlisting>
        echo "using_dma:0" > /proc/ide/hdx/settings
</programlisting>
</para>

<formalpara><title>PPA + IMM</title>
<para>
<!--
Iomega ZIP drives come in a variety of flavours including parallel
port, SCSI, and ATAPI.  The parallel port versions (both old and new)
are driven by ppa and imm respectively.
-->
IOMEGA の ZIP ドライブは、パラレルポート、SCSI、ATAPI といった
さまざまな種類が売られています。パラレルポートタイプは、古い方が ppa ドライバ
で、新しい方が imm ドライバで動作します。
</para>
</formalpara>
<para>
<!--
The parallel port ZIP drives are actually SCSI devices which tunnel
SCSI commands over the parallel port using interfaces called VPI0
(older-style) and VPI2 (newer-style).  The ppa driver is the VPI0 host
implementation and the imm driver is the VPI2 host implementation.
-->
パラレルポートの ZIP ドライブは、実は SCSI デバイスです。VPIO(古い)と
VPI2(新しい)というインタフェースを使って、パラレルポートをトンネルし、
SCSI コマンドを流します。ppa ドライバは、VPIO ホストの実装、imm はVPI2 
ホストで実装です。
</para>
<para>
<!--
The way it works is that the HBA is a chip inside the ZIP drive, so
that the host adapter and the peripheral are in the same actual case.
-->
HBA が ZIP ドライブ内部に搭載されて動作するので、ホスト・アダプタ
と周辺機器が同一筐体にあることになります。
</para>

<formalpara><title>PPSCSI</title>
<para>
<!--
The new, not-yet-integrated, architecture for devices that use SCSI
over a parallel port cable is ppscsi.  The ppscsi module provides the
boiler plate code and makes it easy to write implementations for
different interfaces.
-->
パラレルポートケーブルを利用して SCSI を使用するアーキテクチャに ppscsi が
あります。これは、まだ本体には統合されていない、新しいアーキテクチャです。
ppscsi モジュールはコードが定型化されているので、別のインタフェース向けの
実装を書くのも簡単です。
</para>
</formalpara>
<para>
<!--
Each ppscsi protocol module registers itself with the ppscsi module,
passing in a list of entry points for the various things that are
common to all protocol drivers.
-->
各 ppscsi のプロトコルモジュールは、自分自身を ppscsi モジュールと共に登録
し、プロトコル・ドライバすべてに共通する様々な操作のエントリーポイントを
リストとして渡します。
</para>

    <mediaobject>
      <imageobject>
        <imagedata fileref="ppscsi.eps" format="EPS"/>
      </imageobject>
      <imageobject>
        <imagedata fileref="ppscsi.jpg" format="JPG"/>
      </imageobject>
      <caption><para>
      <!--
			The structure of the PPSCSI drivers.
			-->
			PPSCSI ドライバの構造
      </para></caption>
    </mediaobject>

<para>
<!--
The plan is that the ppscsi architecture will absorb both the ppa and
imm drivers and protocol modules; only vpi0 has been written so far.
See <ulink url="http://www.torque.net/parport/ppscsi.html">
<literal>www.torque.net/parport/ppscsi.html</literal></ulink>.
-->
ppscsi のアーキテクチャでは、ppa と imm ドライバとプロトコルモジュールが
統合される予定になっています。いまのところ VPI0 だけが書かれています。
<ulink url="http://www.torque.net/parport/ppscsi.html">
<literal>www.torque.net/parport/ppscsi.html</literal></ulink> を見て
ください。
</para>

<formalpara><title>USB</title>
<para>
<!--
USB classifies a group of devices as "mass storage" (e.g. disks) and
interacts with these using the SCSI command set. The module name is
"usb-storage".
See <ulink url="http://www.one-eyed-alien.net/~mdharm/linux-usb">
<literal>www.one-eyed-alien.net/~mdharm/linux-usb</literal></ulink>.
-->
USB はあるデバイスのグループを「大容量記憶装置」(例えばディスク)として分類し、
それらと SCSI コマンドセットを使ってやり取りします。モジュール名は、
「usb-storage」です。
<ulink url="http://www.one-eyed-alien.net/~mdharm/linux-usb">
<literal>www.one-eyed-alien.net/~mdharm/linux-usb</literal></ulink> を
見てください。
</para>
</formalpara>
<para>
<!--
There is also the usb/microtek driver for controlling X6 USB scanners
from Microtek. When configured, the SANE application uses the sg
driver to send SCSI commands over USB to control this scanner.
-->
Microtek X6 USB スキャナーを制御する usb/microtek ドライバもあります。
設定されると、SANE アプリケーションは sg ドライバを使って SCSI コマンドを 
USB を通じて送り、このスキャナーを制御します。
</para>

<formalpara><title>I2O</title>
<para>
<!--
See kernel source file <filename>/usr/src/linux/drivers/i2o/io2_scsi.c
-->
カーネルソースの <filename>/usr/src/linux/drivers/i2o/io2_scsi.c 
ファイルを見てください。
</filename>
</para>
</formalpara>

<formalpara><title>IEEE 1394</title>
<para>
<!--
Support for IEEE 1394 devices that use the SBP-2 protocol is now
available (lk 2.4.7). See the IEEE 1394 paragraph in this
<link linkend="ieee1394">section</link> for more information.
-->
SBP-2 プロトコルを使っている IEEE 1394 デバイスが、つい最近利用可能
になりました(Linux カーネル 2.4.7)。後の<link linkend="ieee1394">セクション
</link>の IEEE 1394 の段落にさらに詳しい情報があります。
</para>
</formalpara>

<formalpara><title>iSCSI</title>
<para>
<!--
An IETF draft is taking shape for iSCSI. This sends the SCSI command
set over a TCP network connection. iSCSI seems to be gaining popularity
quickly and there are several implementations for Linux taking shape.
One implementation is at
<ulink url="http://sourceforge.net/projects/intel-iscsi/">
<literal>sourceforge.net/projects/intel-iscsi/</literal></ulink>. 
Use your favourite search engine to find other projects.
-->
iSCSI が IETF のドラフトとしてまとまりつつあります。iSCSI は、SCSI コマンド
セットを TCP のネットワークコネクションを通じて送ります。iSCSI は、一気に普及
しそうに見えますし、Linux でも複数の実装が行われつつあります。
<ulink url="http://sourceforge.net/projects/intel-iscsi/">
<literal>sourceforge.net/projects/intel-iscsi/</literal></ulink> に
そのような実装の 1 つがあります。
お好みの検索エンジンを使って、他のプロジェクトも捜してみてください。
</para>
</formalpara>

</sect1>
</chapter>

<chapter id="rawdev">
  		<!--
      <title>Raw Device</title>
  		-->
      <title>raw デバイス</title>
<para>
<!--
A raw device can be bound to an existing block device (e.g. a disk) and be
used to perform "raw" IO with that existing block device. Such "raw" IO
bypasses the caching that is normally associated with block devices. 
Hence a raw device offers a more "direct" route to the physical device
and allows an application more control over the timing of IO to that
physical device. This makes raw devices suitable for complex applications
like Database Management Systems that typically do their own caching.
-->
raw デバイスは、現在あるブロックデバイス(例えばディスク)に接続でき、それらで
「raw(手を加えない)」IO を行うのに利用できます。
このような「raw」IO は、通常ブロックデバイスに通常付属するキャッシュを迂回
します。
したがって raw デバイスは、物理的なデバイスへの経路がより「直結」している
ので、アプリケーションからその物理デバイスに対する、IO のタイミングを細かく
制御できます。このため raw デバイスは、自身でキャッシュを持つことが多い
データベース管理システムのような、複雑なアプリケーションに適しています。
</para>
<para>
<!--
Raw devices are character devices (major number 162). The first
minor number (i.e. 0) is reserved as a control interface and is usually
found at <filename>/dev/rawctl</filename>. A utility called <command>raw
</command> (see <command>man raw</command>) can be used to bind a raw
device to an existing block device. These "existing block devices" may be
disks or cdroms/dvds whose underlying interface can be anything supported
by Linux (e.g. IDE/ATA or SCSI).
-->
raw デバイスは、キャラクタデバイス(メジャー番号 162)です。最初のマイナー
番号(つまり 0)は、制御用インタフェースとして予約されていて、普通は 
<filename>/dev/rawctl</filename> にあります。<command>raw</command> と呼ばれる
ユーティリティ(<command>man raw</command>を参照)は、raw デバイスを
今あるブロックデバイスに接続するのに利用できます。これらの「今あるデバイス」
としては、ディスクや CD-ROM、DVD などのうち、下層のインタフェースが Linux で
サポートされている(例えば IDE(ATA)や SCSI)ものが該当します。
</para>
<para>
<!--
A sequence of commands listing the raw devices and then binding
a SCSI disk partition followed by binding the whole disk looks
like this on my system:
-->
私のシステムで実行した下記の一連のコマンドは、まず raw デバイスをリストし、
SCSI ディスクのパーティションを接続し、ついでにディスク全体を接続しています。
<programlisting>
$ ls -lR /dev/raw*
crw-r--r--    1 root     root     162,   0 Dec  6 06:54 /dev/rawctl

/dev/raw:
total 0
crw-r--r--    1 root     root     162,   1 Dec  6 06:54 raw1
crw-r--r--    1 root     root     162,   2 Dec  6 06:54 raw2
crw-r--r--    1 root     root     162,   3 Dec  6 06:54 raw3
crw-r--r--    1 root     root     162,   4 Dec  6 06:54 raw4
$
$ raw -qa
$
$ raw /dev/raw/raw1 /dev/sda3
/dev/raw/raw1:  bound to major 8, minor 3
$ raw /dev/raw/raw2 /dev/sda
/dev/raw/raw2:  bound to major 8, minor 0
$ raw -qa
/dev/raw/raw1:  bound to major 8, minor 3
/dev/raw/raw2:  bound to major 8, minor 0
</programlisting>
</para>
<para>
<!--
The normal array of system calls for character devices are available on
raw devices. The size of the transfer for read(2) and write(2) must be
an integral multiple of the physical device's block size. For a disk
this will be its sector size which is normally 512 bytes. The data buffer
given to read() and write() system calls must be aligned to the block 
size. The lseek(2) call needs to align its file read/write offset to a block
boundary as well. The pread(3) call (see <command>man pread</command>)
combines a read() and an lseek() and can be useful with raw devices (ditto with 
pwrite() ). Care should be taken with offsets greater than 2 GB (or perhaps
4 GB) on 32 bit architectures where the "off_t" type is 32 bits long.
One solution is to use the _llseek() call (see <command>man llseek</command>).
-->
キャラクタデバイス用の通常のシステムコール群は、raw デバイスでも
利用できます。read(2)と write(2)が転送する大きさは、物理的なデバイスブロック
サイズの整数倍でなければいけません。これはディスクではセクタの大きさに該当し、
普通は 512 バイトです。read()と write()システムコールに与えられるデータ
バッファは、ブロックの大きさに合わせたものでなければいけません。lseek(2)
システム・コールも、ファイルの読み書きオフセットをブロックの境界にあわせ
なければいけません。pread(3)(<command>man pread</command>を参照)は、
read()と lseek()を兼ね備えたシステムコールで、raw デバイスで便利に使えます
(pwrite()も同様)。32 ビットアーキテクチャ (つまり off_t 型が 32 ビット長) で
2 GB(あるいは 4 GB)以上のオフセットを用いる場合には注意が必要です。
解決方法のひとつは、_llseek()システムコールを用いることです
(<command>man llseek</command>を参照)。
</para>
<para>
<!--
Unix utilities such as recent versions of <command>dd</command> and 
<command>lmdd</command> (from the lmbench suite of programs) can be used
to move data to and from "raw" devices as they meet the above-mentioned
block alignment requirements. Recent versions of the <command>sg_dd</command>
command in the sg_utils package can access both raw and sg devices.
-->
最近のバージョンの <command>dd</command> や <command>lmdd</command>(lmbench 
に入っているプログラム)のような Unix ユーティリティは、上述のブロックアライン
メントを行えるので、「raw」デバイスとデータをやり取りできます。sg_util 
パッケージに入っている最近のバージョンの <command>sg_dd
</command> コマンドは、raw デバイスにも sg デバイスにもアクセスできます。
</para>
<para>
<!--
Also note that if the physical device has an odd number of sectors (as 
shown by <command>blockdev &#045;&#045;getsize /dev/raw/raw*</command>), the last
sector will not be accessible using raw IO.
-->
物理デバイスのセクタ数が奇数だと(<command>blockdev --getsize 
/dev/raw/raw*</command>)でわかります)、raw 入出力では最後のセクタにアクセス
できません。
</para>
<warning>
<para>
<!--
If a block device is being accessed via a bound raw device and also via
its normal block interface then there is no cache coherency between the
two access mechanisms. For example if <filename>/dev/sda1</filename> was
both mounted and being accessed via a bound raw device then there could be
data inconsistencies.
-->
あるブロックデバイスに対して、そのデバイスに対応している raw デバイス経由で
アクセスし、かつ通常のブロックインタフェース経由でもアクセスすると、2 つの
アクセス機構間でキャッシュの一貫性が保てません。例えば 
<filename>/dev/sda1</filename> が両者でマウントされ、接続している raw デバイス
経由でアクセスされると、データに不整合が発生するかもしれません。
</para>
</warning>
</chapter>

<chapter id="devfs">
      <!--
  		<title>Devfs pseudo file system</title>
  		-->
  		<title>devfs 擬似ファイルシステム</title>
<para>
<!--
The main documentation for devfs can be found at: reference
<link linkend="W5">W5</link>. The devfs name conventions for the
SCSI subsystem are outlined in <xref linkend="dnamesdevfs"/>.
Devfs is selected by the kernel build option CONFIG_DEVFS_FS and whether
it is mounted at boot time (as <filename>/dev</filename>) or not is
controlled by the kernel build option CONFIG_DEVFS_MOUNT. The latter option
can be overridden by the kernel boot time options "devfs=mount" or
"devfs=nomount", whichever is appropriate.
-->
devfs の中核的なドキュメントは、<link linkend="W5">W5</link>を参考にしてく
ださい。
SCSI サブシステムにおける devfs の命名規則の概要は、
<xref linkend="dnamesdevfs"/>にあります。
devfs は、カーネル構築オプションの CONFIG_DEVFS_FS で選択します。
ブート時に(<filename>/dev</filename> として)マウントされるかどうかは、
カーネル構築オプションの CONFIG_DEVFS_MOUNT で決まります。
後者のオプションは、カーネルブート時のオプションである「devfs=mount」
もしくは「devfs=nomount」の好きな方どちらによっても変更できます。
</para>
<para>
<!--
The devfs SCSI node names with their default permissions are:
-->
devfs の SCSI ノード名と、デフォルトのパーミッションは下記の通りです。
<programlisting>
disc        rw-------   whole disk including mbr
part1       rw-------   first partition {...p1}
...
part15      rw-------   15th partition {...p15}
cd          rw-rw-rw-   cd or dvd devices
mt          rw-rw-rw-   tape mode 0 with rewind {...m0}
mtl         rw-rw-rw-   tape mode 1 with rewind {...m1}
mtm         rw-rw-rw-   tape mode 2 with rewind {...m2}
mta         rw-rw-rw-   tape mode 3 with rewind {...m3}
mtn         rw-rw-rw-   tape mode 0 with no rewind {...m0n}
mtln        rw-rw-rw-   tape mode 1 with no rewind {...m1n}
mtmn        rw-rw-rw-   tape mode 2 with no rewind {...m2n}
mtan        rw-rw-rw-   tape mode 3 with no rewind {...m3n}
generic     rw-r-----
</programlisting>
</para>
<para>
<!--
These node names are only present if the corresponding device (or sub-entities
of the device (e.g. partitions)) and driver are present. For example if
there is no sg driver present then there is no "generic" device name. The
strings that appear above in braces are appended to the abridged "c0b0t0u0"
notations outlined below as appropriate.
-->
これらのノード名は、対応しているデバイス(もしくはデバイスのサブエントリー
(例えばパーティション))とドライバが存在する時にだけ現れます。例えば 
sg ドライバがなければ「汎用」デバイス名は存在しません。上記の
｛｝中の文字列は、下記で説明する「c0b0t0u0」という簡略表記の後ろに適宜追加
されます。
</para>
<para>
<!--
The devfs file names that are block or character special files will be
called the primary device names in this description. The devfs daemon, called
devfsd, introduces many symbolic links to those primary device names. This is
done both for backward compatibility and convenience. These symbolic links
will be called secondary device names.
-->
ブロックスペシャルファイルやキャラクタスペシャルファイルになっている devfs 
ファイル名を、ここではプライマリデバイス名と呼びます。devfs のデーモン 
devfsd は、これらのプライマリデバイス名に対してたくさんの
シンボリックリンクを張っています。これは下位互換性と利便性のためです。
これらのシンボリック・リンクは、セカンダリデバイス名と呼びます。
</para>
<para>
<!--
The secondary device names are controlled by the devfsd configuration file
usually found in <filename>/etc/devfsd.conf</filename> . Following is a
list of secondary device names when the default devfsd.conf file is used:
-->
セカンダリデバイス名は、devfsd の設定ファイルで制御されます。設定ファイル
は通常 <filename>/etc/devfsd.conf</filename> です。デフォルトの devfsd.conf 
ファイルを使うと、セカンダリデバイス名は下記のリストになります。
<programlisting>

<!--
Secondary name       slink to this primary device name
-->
セカンダリ名         プライマリデバイス名へのシンボリックリンク
--------------------------------------------------------------
/dev/sda             /dev/scsi/host0/bus0/target2/lun0/disc
/dev/sda1            /dev/scsi/host0/bus0/target2/lun0/part1
/dev/sd/c0b0t2u0     /dev/scsi/host0/bus0/target2/lun0/disc
/dev/sd/c0b0t2u0p1   /dev/scsi/host0/bus0/target2/lun0/part1
/dev/sr0             /dev/scsi/host0/bus0/target4/lun0/cd
/dev/sr/c0b0t4u0     /dev/scsi/host0/bus0/target4/lun0/cd
/dev/st0             /dev/scsi/host1/bus0/target0/lun0/mt
/dev/nst0a           /dev/scsi/host1/bus0/target0/lun0/mtan
/dev/st/c1b0t0u0m0   /dev/scsi/host1/bus0/target0/lun0/mt
/dev/st/c1b0t0u0m3n  /dev/scsi/host1/bus0/target0/lun0/mtan
/dev/sg0             /dev/scsi/host0/bus0/target2/lun0/generic
/dev/sg1             /dev/scsi/host0/bus0/target4/lun0/generic
/dev/sg2             /dev/scsi/host1/bus0/target0/lun0/generic
/dev/sg/c0b0t2u0     /dev/scsi/host0/bus0/target2/lun0/generic
/dev/sg/c0b0t4u0     /dev/scsi/host0/bus0/target4/lun0/generic
/dev/sg/c1b0t0u0     /dev/scsi/host1/bus0/target0/lun0/generic
</programlisting>
</para>
<para>
<!--
Note that the more common <filename>/dev/scd0</filename> variant for SCSI
cdroms is not supported. There are also <filename>/dev/discs</filename>, 
<filename>/dev/cdroms</filename> and <filename>/dev/tapes</filename>
directories that contain symbolic links to all devices (i.e. not just
SCSI devices) that fall into that categorization:
-->
SCSI CD-ROM 用として良く使われる <filename>/dev/scd0</filename> 系が
サポートされていないことに気づきましたか。<filename>/dev/discs</filename>、
<filename>/dev/cdroms</filename>、<filename>/dev/tapes</filename> 
といった、そのカテゴリに入るデバイスすべて(つまり、SCSI デバイスに限らない)
に対するシンボリックリンクを集めたディレクトリも存在します。
<programlisting>

<!--
Secondary name       slink to this primary device
-->
セカンダリ名         プライマリデバイスへのシンボリックリンク
------------------------------------------------------------
/dev/discs/disc0     /dev/ide/host0/bus0/target0/lun0      *
/dev/discs/disc1     /dev/scsi/host0/bus0/target2/lun0     *
/dev/cdroms/cdrom0   /dev/ide/host0/bus1/target1/lun0/cd
/dev/cdroms/cdrom1   /dev/scsi/host0/bus0/target4/lun0/cd
/dev/tapes/tape0     /dev/scsi/host1/bus0/target0/lun0     *
</programlisting>
</para>
<para>
<!--
Those entries marked with "*" are directories containing the primary devices.
Note that IDE/ATA devices are listed before SCSI devices. These secondary device
names mimic the same persistence rules as the primary device names. So when
a SCSI device (?), or its lower level driver or its upper level driver are
removed then so are the primary and secondary device names associated with it.
-->
「*」がついた項目は、プライマリデバイスがあるディレクトリです。
IDE(ATA)デバイスは SCSI デバイスの前にリストされます。これらセカンダリ
デバイス名の永続性は、プライマリデバイス名と同じ規則に従います。
したがって、SCSI デバイス(？)もしくはその低レベルもしくは高レベルのドライバ
が削除されると、対応していたプライマリ・セカンダリデバイス名も削除されます。
</para>
<para>
<!--
When devfs is mounted as <filename>/dev</filename>, the old 
"<filename>/dev/sda6</filename>" type can still be used
in some contexts. This may be convenient if typing is required at the
kernel boot time prompt. For example if a user wants to change the root
partition on a "devfs" machine then any of the following examples
may be used as a kernel boot time option:
-->
devfs が <filename>/dev</filename> でマウントしてある場合でも、
以前の <filename>/dev/sda6</filename> もある状況下では利用できます。これは
カーネルブート時に入力が必要な場合に便利でしょう。例えばユーザが「devfs」を
使っているマシンのルートパーティションを変更したい場合は、下記のブート時
オプションのいずれも使えます。
<programlisting>
   root=/dev/sda6
   root=/dev/scsi/host0/bus0/target0/lun0/part6
   root=/dev/sd/c0b0t0u0p6
</programlisting>
</para>
<para>
<!--
There are many device scanning programs that expect to see the pre-devfs
device names present and it will some time before they become devfs aware.
Also some programs rely on a open of <filename>/dev/sg0</filename>
(for example) to load the
sg driver (assuming it is a module and not already loaded). This can
be arranged by an entry in <filename>/etc/devfsd.conf</filename> file of:
-->
プログラムの中には、デバイスをスキャンする際に devfs 以前のデバイス名を
想定しているものがたくさんあります。それらのプログラムが devfs を
認識するまでにはしばらく時間がかかりるでしょう。
また、sg ドライバのロード
(モジュールになっていて、まだロードされていない場合)を、(例えば)
<filename>/dev/sg0</filename>のオープンによって行うようなプログラムも
あります。これについては
<filename>/etc/devfsd.conf</filename> の次の項目で調整できます。
<programlisting>
        LOOKUP          sg.*            MODLOAD
</programlisting>
<!--
and the following in <filename>/etc/modules.devfs</filename> :
-->
そして <filename>/etc/modules.devfs</filename> は下記のようになります。
<programlisting>
        probeall        /dev/sg         scsi-hosts sg
        alias           /dev/sg*        /dev/sg
</programlisting>
</para>
<para>
<!--
The sg device permissions can be changed with this entry in the 
<filename>/etc/devfsd.conf</filename> file:
-->
sg デバイスのパーミッションは、<filename>/etc/devfsd.conf</filename> ファイル
の項目で調整できます。
<programlisting>
  REGISTER scsi/host.*/bus.*/target.*/lun.*/generic
                              PERMISSIONS 0.0 rw-rw-rw-
</programlisting>
<!--
See "man devfsd" for more information.
-->
詳しくは、「man devfsd」を見てください。
</para>
<para>
<!--
An application can determine whether devfs is active by the presence or
otherwise of the file <filename>/dev/.devfsd</filename>.
-->
アプリケーションから devfsd が動作中かどうかを判断するのに、
<filename>/dev/.devfsd</filename> の有無が使えます。
</para>
<para>
<!--
A feature of a /dev directory based on a persistent file system (e.g.
ext2) is the ability to associate permissions with a device file name
and keep them from one boot to the next. As noted above the default
action of devfs is to assign device file name permissions anew each time
a machine is booted. The PERMISSIONS action in the <filename>
/etc/devfsd.conf</filename> can be used to assert permissions but
this may be considered a little awkward. The devfs document
(<link linkend="W5">W5</link>) describes a method for getting the best
of both worlds. This technique relies on the recently added feature
in lk 2.4 to mount the same file system at multiple points.
-->
永続的なファイルシステム(例えば ext2)に基づく /dev ディレクトリの特徴のひとつ
に、デバイスファイル名とパーミッションとを関係付け、それをブートとブートの間
にも維持する機能が挙げられます。上記で述べたように、devfs のデフォルトの動作
では、マシンがブートするごとにデバイスファイル名のパーミッションを割り当て
ます。<filename>/etc/devfsd.conf</filename> の PERMISSION 動作をパーミッション
指定に使えますが、これは少々面倒だと思います。
devfs のドキュメント(<link linkend="W5">W5</link>)では、一石二鳥な方法を記述
されています。このテクニックは Linux カーネル 2.4 に最近追加された、複数の
場所に同じファイルシステムをマウントする機能によるものです。
</para>
</chapter>


<appendix id="scsibus">
  		<!--
      <title>Common bus types (SCSI and other)</title>
  		-->
      <title>一般的なバスの種類(SCSI 等)</title>
<para>
<!--
A very good overview of the various bus types touched on in this
appendix (both SCSI and others) can be found at
<ulink url="http://www.pctechguide.com/04disk2.htm">
<literal>www.pctechguide.com/04disk2.htm</literal></ulink>.
-->
この付録で触れる様々なバスの種類(SCSI もその他も)の概観としては、
<!--
<ulink url="http://www.pctechguide.com/04disk2.htm">
<literal>www.pctechguide.com/04disk2.htm</literal></ulink>が非常に優れて
います。
-->
www.pctechguide.com/04disk2.htm が非常に優れています。
(注: リンク切れです。- 2006-08-06 JF Project)
</para>
<formalpara><title>SCSI</title>
<para>
<!--
The original SCSI 1 standard (ANSI specification X3.131-1986) introduced
an 8 bit parallel bus that was able to do asynchronous transfers at 1.5
MegaBytes/sec and synchronous transfers up to 5 MB/sec. SCSI commands are
sent at the asynchronous rate. SCSI data is transferred either at the
asynchronous rate (worst case) or a negotiated synchronous rate (with
5 MB/sec being the best case).
-->
オリジナルの SCSI 1 規格(ANSI 規格 X3.131-1986)は、8 ビットのパラレルバス
です。非同期で 1.5 MB/sec、同期で 5 MB/sec までの転送ができることになって
いました。SCSI コマンドは非同期で送られます。SCSI データは非同期(最悪の
場合)もしくは、ネゴシエーションをして同期(最善で 5 MB/sec)で送られます。
</para>
</formalpara>
<formalpara><title>FAST SCSI</title>
<para>
<!--
The SCSI 2 standard raised the maximum synchronous speed to 10 MB/sec. SCSI 2
defined several parallel buses: single ended (as used by SCSI 1) and a new
differential bus. The differential bus has better noise immunity and its
maximum bus length is 25 metres (compared with single ended's 6 metres).
Tagged queuing of commands was also added by SCSI 2.
-->
SCSI 2 規格は、最大同期速度が 10 MB/sec まで上がりました。SCSI 2 では
パラレルバスがいくつか定義してあります。シングルエンド(SCSI 1 で使用)と、
新規のディファレンシャルバスです。ディファレンシャルバスは、耐ノイズ性
に優れ、最大バス長が 25 m になりました(これに対してシングルエンドは 6 m)。
タグキューのコマンドも SCSI 2 で追加されました。
</para>
</formalpara>
<formalpara><title>WIDE SCSI</title>
<para>
<!--
The SCSI 2 standard also increased the width of the bus allowing 16 and 32 bit
"wide" variants. Very little use has been made of the 32 bit width so "wide"
usually refers to a 16 bit wide data path. The maximum number of SCSI devices
that can connect to a parallel SCSI bus is directly related to the bus width
hence "wide" buses allow a maximum of 16 SCSI devices to be connected.
[At least one of those devices must be the SCSI "initiator" which is
usually a host adapter.]
-->
SCSI 2 規格ではバス幅も広がり、16 と 32 ビットの(wide)な変種が認められました。
32 ビット幅はほとんど使われていませんので、「wide」は通常 16 ビット幅のデータ
パスを指します。パラレルバスに接続できる SCSI デバイスの最大数は、バス幅
に密接に関連しており、「wide」バスには最大 16 個の SCSI デバイスが接続
可能です。(デバイスの内少なくとも 1 つは SCSI「イニシエータ」でなければ
いけませんい。通常イニシエータはホスト・アダプタ)。
</para>
</formalpara>
<formalpara><title>ULTRA SCSI</title>
<para>
<!--
Traditionally synchronous buses are clocked either on the rising or falling
edge of the clock (which is normally a square wave). A recent trend has been
to clock on both edges and thus double the available bandwidth. This is
how ULTRA SCSI doubles the SCSI 2 "fast" speed to 20 MB/sec.
-->
これまで同期式のバスは、クロック(通常は方形波)の立ち上がりと立ち下がりどちらか
で同期を取ってきましたが、最近はクロックの立ち上がりと立ち下がり両方でクロック
を取り、利用できる帯域幅を倍にする傾向にあります。
この方法によって、ULTRA SCSI は SCSI 2 を「高速」にして 20 MB/sec となりました。
</para>
</formalpara>
<formalpara><title>ULTRA WIDE SCSI</title>
<para>
<!--
The same "ultra" technique applied to a (16 bit) wide SCSI parallel bus yields
a bandwidth of 40 MB/sec.
-->
「ULTRA」と同じ技術を(16 ビット)の wide SCSI パラレルバスに適用し、帯域幅を 
40 MB/sec にしています。
</para>
</formalpara>
<formalpara><title>ULTRA 2 WIDE SCSI</title>
<para>
<!--
This variant introduces a new "low voltage" differential signalling (LVD) that
allows the synchronous clock speed to be doubled yielding 80 MB/sec when using
a (16 bit) wide bus. In this case the maximum SCSI bus length is 12 metres. To
be backward compatible with ULTRA WIDE this variant can fall back to "single
ended" operation. This leads to the abbreviation LVD/SE being used by adapter
manufacturers. One shortcoming of this approach is that the presence of one
UW device on a U2W bus will cause all other U2W devices to communicate at
the slower (i.e. UW) rate. Some adapters overcome this by having separate
LVD and SE physical buses on the same logical SCSI bus.
-->
このタイプは、新しい「低電圧」版のディファレンシャルな信号形式(LVD)で、
同期クロック速度を倍にし、(16 ビット)wide バスを使って 80 MB/sec にして
います。
この場合の、SCSI バス長は最長 12 m です。ultra wide との下位互換性のため、
「シングルエンド」での操作も可能になっています。これには、LVD/SE という
略語がアダプタ製造メーカーによって使われています。この取り組み方の欠点の
1 つに、U2W バス上に UW デバイスが存在していると、他の U2W デバイスの速度
が遅くなって(つまり、UW になって)しまう点があります。アダプタには、論理的
には同一の SCSI バス上でありながら、物理的に LVD と SE を独立したバスに載せ、
この欠点を補っているものもあります。
</para>
</formalpara>
<formalpara><title>ULTRA 160 SCSI</title>
<para>
<!--
ULTRA 160 doubles parallel SCSI bus bandwidth yet again. It uses a 16 bit
wide data path, LVD signalling (see previous entry) and double transition
clocking that increases the maximum synchronous bandwidth to 160 MB/sec.
Additional features include cyclic redundancy codes (CRC) to improve data
integrity (compared with a parity bit) and domain validation which adjusts
transfer rates if the error rate is too high.
-->
ULTRA 160 は、パラレル SCSI のバス幅をさらにまた倍にしています。16 
ビット幅のデータバスに LVD の信号形式(先の項目を参照)を使っています。
さらに DT(Double Transition)クロックにより、同期帯域幅は最高で 160 
MB/sec になります。
追加機能として巡回冗長検査(CRC)が加わり、データの整合性が(パリティビットと
比べて)向上しています。またエラー率があまりに高くなると、転送速度を調整する
ドメインバリデーション(domain validation)も加わっています。
<quote>
【訳註：ULTRA 160 までの SCSI 一般についての説明は、
<ulink url="http://www.adaptec.co.jp/about_scsi/book2/">adaptec 社の 
SCSI HAND BOOK(日本語)</ulink>を参照してください】
</quote>
</para>
</formalpara>
<formalpara><title>ULTRA 320 SCSI</title>
<para>
<!--
Shortly ULTRA 320 adapters will be available (disks with that interface
are already on the market). This is also a 16 bit wide LVD bus that can
fall back to slower speeds for compatibility with older devices. It extends
the features of Ultra 160 by doubling the clock speed. Packetized SCSI
which sends commands and status at full bus speed (rather than 5 MB/sec)
is included. Other improvements include "quick arbitration and selection",
"read and write data streaming" and CRC protection for command blocks as well
as data (Ultra 160 had CRC protection for data only). Note that adapter
cards using 64 bit PCI (or better: PCI-X) are required to stop the PCI bus
being a bottleneck at these speeds. More information can be found at
<ulink url="http://www.scsita.org"><literal>www.scsita.org</literal></ulink>.
Recently an Ultra 320 HBA vendor claimed up to 105,000 IO operations 
per second which implies per command SCSI bus overhead is less than 10
microseconds. There is a draft ULTRA 640 standard but that may be overtaken 
by Serial Attached SCSI.
-->
まもなく ULTRA 320 アダプタが登場します(このインタフェースを持ったディスク
はすでに市場に出ています)。この規格も 16 ビット幅の LVD バスです。古い
デバイスに対する互換性を保つために速度を落とせます。
クロック速度を倍にして、Ultra 160 の能力を向上させています。
コマンドとステータスを (5MB/sec ではなく) バンド幅のフル速度で送る、
Packetized SCSI という機能も含まれます。
その他の改良点として、「quick arbitration and selection(QAS)」や
「read and write data streaming」、データと同様に
コマンドブロックを保護する CRC プロテクションがなどがあります(Ultra 160 は
データに対してだけ CRC プロテクションが有効)。このような速度になると、PCI 
バスをボトルネックにしないためには、64 ビット PCI (さらに良いのは PCI-X)
カードが必要とされます。さらに詳しい情報は、
<ulink url="http://www.scsita.org"><literal>www.scsita.org</literal></ulink>
を見てください。
最近になって Ultra 320 の HBA ベンダーは、秒あたりの入出力操作が 105,000 に
まで達したと言っています。これは、コマンド当たりの SCSI バスのオーバーヘッド
が 10 ms 以内ということになります。ULTRA 640 規格のドラフトもありますが、
シリアルアタッチド SCSI に取って代わられるでしょう。
<quote>
【訳註：「quick arbitration and selection(QAS)」と「read and write data 
streaming」については、
<ulink url="http://www.adaptec.com/worldwide/product/markeditorial.html?prodkey=ultra320_whitepaper">米 adaptec 社の Ultra320 SCSI: New Technology-Still SCSI
</ulink>を参照してください】
</quote>
</para>
</formalpara>
<!--
<formalpara><title>Serial Attached SCSI (SAS)</title>
-->
<formalpara><title>シリアルアタッチド SCSI(SAS)</title>
<para>
<!--
Serial Attached SCSI (SAS) uses the same transport technology as Serial
ATA (sATA) and extends it. [sATA is described below.] SAS can use external 
expanders to control up to 4096 (?) devices from a single HBA circuit. The 
data transfer is full duplex and 1.5 Gbps "phys"s can be aggregated to 
increase bandwidth. Cable lengths can be up to 6 meters. SAS disks are 
dual ported. sATA disks can be connected to a SAS HBA (but SAS disks can't
be connected to a sATA HBA). SAS was demonstrated at CeBit recently but 
won't reach the market until 2004.
-->
シリアルアタッチド SCSI(SAS)は、シリアル ATA(sATA)と同じ転送技術を、
さらに拡張して使うものです。(sATA については後述)。SAS では、外部エクスパンダ
を使って、4096(?)個のデバイスをひとつの HBA 回路で制御できます。
データ転送は全二重で、1.5 Gbps の「束」をまとめ、帯域を広げられます。
ケーブル長は 6 m までです。SAS ディスクはデュアルポートになっています。
sATA ディスクは、SAS HBAに接続できます(ただし、SAS ディスクは sATA HBA には
接続できません)。
SAS は、最近 CeBit(国際事務情報/通信技術見本市)でデモが行われましたが、
2004 年までは市場には出ないでしょう。
<quote>
【訳註：外部エクスパンダについては、
<ulink url="http://www.adaptec.co.jp/about_scsi/book2/">adaptec 社の 
SCSI HAND BOOK(日本語)</ulink>を参照してください】
</quote>
</para>
</formalpara>
<formalpara><title>FC-AL</title>
<para>
<!--
This stands for Fibre Channel - Arbitrated Loop and may involve dual
2 Gigabit per second single mode fibre optic links spanning 10 
kilometres with throughput of up to 400 MegaBytes per second.
Often associated with storage area networks (SANs). Up to 126
devices can be attached to a loop which in turn can be extended
to 16 million devices in public loop mode. The transmission medium
isn't necessarily fibre optic cable: copper (in the form of co-axial
cable) can also be used at lower speeds and for shorter distances.
-->
これは、ファイバチャネルアービトレイトループを意味し、2 GB/sec の
シングルモード光ファイバーをデュアルで接続し、10 Km の経路で 400 MB/sec 
の流量を流します。
storage area network(SAN)と連携するケースがよくあります。ループには 126 
デバイスまで接続できます。public loop モードにするとさらに拡張が可能で、
1600 万もの接続が可能になります。転送媒体には光ケーブルでなくても構い
ません。
低速で経路が短かければ、メタルケーブル(同軸ケーブル)も使用できます。
</para>
</formalpara>
<formalpara><title>IEEE 1394</title>
<para>
<anchor id="ieee1394"/>
<!--
This standard also goes by the name of "Fire Wire" [trademarked
by Apple] and "iLink" [trademarked by Sony]. It is a serial bus that can run
at up to 400 Megabits/sec. It has a similar but more general architecture than
USB. The IEEE 1394 standard allows for the SCSI command set to be
carried over a 1394 bus. There is a "sbp2_1394" driver now available for
the Linux IEEE 1394 stack. This sbp2_1394 driver is also a SCSI subsystem
lower level driver (so it is functionally similar to the ide-scsi driver).
So IEEE 1394 devices that use the SBP-2 protocol (e.g. disks, cd-rw/dvd
drives, MO drives and scanners) can be accessed via the SCSI subsystem.
See <ulink url="http://Linux1394.sourceforge.net">
<literal>Linux1394.sourceforge.net</literal></ulink> for more information.
The sbp2 driver is now in lk 2.4.7 .
-->
この規格は、「Fire Wire」(APPLE の商標)とも「iLink」(SONY の商標)とも
呼ばれています。シリアルバスで、400 MB/sec まで動作します。USB と似て
いますが、より汎用的な構造になっています。IEEE 1394 規格では、SCSI コマンド
セットを 1394 バスに載せています。Linux の IEEE 1394 スタックとしては、
「sbp2_1394」ドライバが利用可能になりました。この sbp2_1394 ドライバは、
SCSI サブシステムの低レベルなドライバでもあります(よって機能的には ide-scsi 
ドライバと似ています)。
つまり、SBP-2 プロトコルを使用した IEEE 1394 デバイス(例えばディスク、
CD-RW、DVD ドライブ、MO ドライブ、スキャナー)には、SCSI サブシステムを通じて
アクセスします。
<ulink url="http://Linux1394.sourceforge.net">
<literal>Linux1394.sourceforge.net</literal></ulink> に詳しい情報があります。
sbp2 ドライバは、Linux カーネル 2.4.7 に取り込まれました。
</para>
</formalpara>
<formalpara><title>iSCSI</title>
<para>
<!--
This is an emerging IETF standard for sending the SCSI command set over a
TCP connection (or several of them). This will permit SCSI devices (targets
such as disks) to be network appliances, accessed locally (or potentially
at a great distance) by a host machine.
-->
これは SCSI コマンドセットを TCP 接続(もしくはそれらの内のいくつか)で送る、
新たな IETF 規格です。これは SCSI デバイス(ターゲットはディスクのようなもの)
をネットワーク機器とし、ホストマシンからローカルに(もしくは遠距離から)
アクセスすることを可能とします。
</para>
</formalpara>

<!--
<formalpara><title>NON SCSI buses</title>
-->
<formalpara><title>SCSI 以外のバス</title>
<para>
<!--
The following buses are not defined by the SCSI standards but are of interest
because they either can carry the SCSI command set, are in some way
related to the Linux SCSI subsystem or supply a similar functionality to
SCSI products.
-->
これから述べるバスは SCSI 規格では定義されていませんが、SCSI コマンドセット
も運べること、ある面で Linux の SCSI サブシステムに関連していること、SCSI 
製品と同様の機能を提供することなど、本文書の対象となりうるものです。
</para>
</formalpara>

<formalpara><title>IDE/ATA (ATAPI)</title>
<para>
<!--
IDE is the most used disk type on PC systems today. The acronym stands for
Integrated Drive Electronics and as the name suggests it places the bulk
of the IO "intelligence" on the disk controller card rather than spreading
it between the device (most often a disk) and a controller (HBA) as SCSI
does. IDE grew out of the ST506 and ESDI standards in the 1980s. EIDE
(extended IDE) is a related acronym. The modern standards that refer to
this bus architecture are known as ATA and can be found at 
<ulink url="http://www.t13.org">
<literal>www.t13.org</literal></ulink>. The ATA Packet Interface (ATAPI)
extends the disk oriented command set to support CDROM and tape drives.
The ATAPI command set closely resembles the SCSI command set. The
most recent ATA technology is outlined in the next paragraph.
-->
IDE は、PC システムで現在最も普及しているタイプのディスクです。頭文字は、
Integrated Drive Electronics を表しています。名前が示す通り、IDE では
IO の「知能」をディスクコントローラカードに集中させています。これに対し、
例えば SCSI では、IO 機能をデバイス(たいていはディスク)とコントローラ(HBA)
間に分散させています。
IDE は、1980 年代に ST506 と ESDI 規格からはじまりました。EIDE(extended IDE)
は、同類の略語です。このバスアーキテクチャを指す最近の規格は ATA として
知られており、<ulink url="http://www.t13.org">
<literal>www.t13.org</literal></ulink> で見られます。ATA のパケットインタ
フェース(ATAPI)は、ディスク指向のコマンドセットを拡張して、CD-ROM や
テープドライブをサポートしています。ATAPI のコマンド・セットは、SCSI 
コマンドセットと非常に似ています。最新の ATA 技術については、次の節で紹介
します。
</para>
</formalpara>

<formalpara><title>ATA 133</title>
<para>
<!--
The ATA standards used by IDE devices have also been marching through
the adjectives (e.g. fast and ultra) and the numbers (e.g. 2, 33,
66, 100 and 133). The most recent addition is ATA 133 which supports
burst rates of 133 MB/sec and up to 2 devices per bus. [PCs typically
have 2 and often 4 ATA buses.] ATA 66, 100 and 133 need a special cable.
ATA cables are relatively short precluding IDE devices being external to
the computer. Cable lengths have previously been limited to 18 inches
although 1 metre long cables have now appeared. Coincidently 133 MB/sec
in also the maximum throughput of the normal PCI bus found in most
PCs. The are higher speed (and wider) versions of PCI but they are
relatively rare.
-->
IDE デバイスが使用する ATA 規格も、形容詞(例えば fast や ultra)や数字(例えば 
2、33、66、100、133)が並んできました。最も新しく加わったのは ATA 133 で、
バーストで 133 MB/sec の速度とバス当たり 2 つまでのデバイスをサポートして
います。(PC には通常、2 本 または 4 本の ATA バスがあります)。
ATA 66、 100、133 には、専用のケーブルが必要になります。
ATA ケーブルはかなり短く、コンピュータ外部に IDE デバイスが置けないのはこの
せいです。ケーブル長はこれまで 46 cm が限度でしたが、最近になって 1 m のもの
が出てきました。133 MB/sec という値は、おおかたの PC の最大転送速度でもあり
ます。より高速(かつ帯域も広い)バージョンの PCI もありますが、まだそれほど
普及しているわけではありません。
</para>
</formalpara>

<!--
<formalpara><title>Serial ATA (sATA)</title>
-->
<formalpara><title>シリアル ATA (sATA)</title>
<para>
<!--
Serial ATA uses 2 differential pairs to exchange data with a sATA
disk less than 1 metre away at 1.5 Gigabits per second. One pair takes data
to the disk and the other returns data from the disk. Data rates up to
150 Megabytes per second are possible (data transfer is half duplex).
sATA is a point to point connection, not a bus, so ATA's master and slave
strapping disappears. sATA cabling is less bulky and the form factor of
its plugs and sockets are smaller than parallel ATA (and the SCSI Parallel
interface). sATA devices are beginning to appear on the market. sATA-2
is a draft standard that doubles the serial data rate to 3 Gigabits per
second.
-->
シリアル ATA はディファレンシャルのペアを 2 組使い、1 つはディスクからデータを
sATA ディスクとデータ
を交換します。1 m 以内の距離で 1.5 G ビット/sec で転送します。1 組はデータ
をディスクに送り、もう 1 つはディスクからデータを受けます。データ速度は、
150 MB/sec まで可能です(データ転送は半二重)。
sATA はポイント‐ポイント接続で、バス接続ではありませんので、ATA の
マスターとスレーブという関係は存在しません。sATA の配線はすっきりして
いて、プラグやソケットの形状もパラレル ATA(と SCSI パラレルインタフェース)
より小ぶりです。sATA デバイスは市場に出はじめたところです。sATA-2 はドラフト
規格で、シリアルのデータ転送量が 3 G ビット/sec になっています。

</para>
</formalpara>

<formalpara><title>USB</title>
<para>
<!--
Universal Serial Bus (USB) has a bandwidth of between 1.5 and 12
Megabits/sec (the latter speed with USB 1.1). Up to 127 devices can
be connected using a series of hubs each of which connects up to 7
devices (with a 5 metre limit). USB supplies 5 volts at 0.5 amps to
power small devices. USB is "plug and play", hot pluggable and supports
isochronous data transfers (required for audio and video devices that
need guaranteed minimum bandwidth).
-->
ユニバーサルシリアルバス(USB)は、帯域幅が 1.5 から 12 M ビット/sec
(後者の速度は USB 1.1)です。ハブそれぞれに最大 7 つのデバイスが接続でき、
ハブを複数用いて 127 個までのデバイスが接続できます(長さの限界は 5 m)。
USB は、低消費電力デバイス向けに、 5 V 0.5 A を供給します。USB は「プラグ
アンドプレイ」で、ホットプラグができ、同期転送をサポートします(最低帯域幅
保証が必要なオーディオやビデオデバイスに適しています)。
</para>
</formalpara>

<!--
<formalpara><title>PC Parallel port</title>
-->
<formalpara><title>PC パラレルポート</title>
<para>
<!--
The original PC parallel port was uni-directional (towards the printer)
and was capable of about 10 KB/sec. The IEEE 1284 standard in 1994
introduced 5 modes of data transfer:
-->
もともと PC についているパラレルポートは片方向(プリンター向き)で、
約 10 KB/sec の能力がありました。1994 年の IEEE 1284 規格では、データ転送
方法が 5 種類ありました。
<itemizedlist>
<!--
<listitem><para>Compatibility mode (forward direction)</para></listitem>
<listitem><para>Nibble mode (reverse direction)</para></listitem>
<listitem><para>Byte mode (reverse direction)</para></listitem>
<listitem><para>EPP mode (bi-directional)</para></listitem>
<listitem><para>ECP mode (bi-directional)</para></listitem>
-->
<listitem><para>互換モード(順方向)</para></listitem>
<listitem><para>ニブルモード(逆方向)</para></listitem>
<listitem><para>バイトモード(逆方向)</para></listitem>
<listitem><para>EPP モード(双方向)</para></listitem>
<listitem><para>ECP モード(双方向)</para></listitem>
</itemizedlist>
<!--
Enhanced Parallel Port (EPP) achieves transfer speeds of between 500 KB/sec
and 2 MB/sec and is targeted at CD-ROMs, tapes and hard drives. Extended
Capability Port (ECP) includes run length encoding and support for DMA.
ECP is targeted at fast printers and scanners.
-->
エンハンスドパラレル・ポート(EPP)は、転送速度が 500 KB/sec から 2 MB/sec 
の間になり、CD-ROM、テープ、ハードドライブをターゲットにしています。
エクステンデッドケイパビリティポート(ECP)は、ラン・レングス符号化を
取り入れ、DMA をサポートしています。
ECP は高速なプリンターやスキャナーをターゲットにしています。
</para>
</formalpara>

<formalpara><title>I2O</title>
<para>
<!--
"The I2O (Intelligent Input/Output) specification defines a standard
architecture for intelligent I/O that is independent of both the specific
device being controlled and the host operating system (OS)" [from <ulink 
url="http://www.i2osig.org"><literal>www.i2osig.org</literal></ulink>].
It defines a "split driver" model in which the OS Services Module (OSM)
sits between the host OS device interface and the I2O communications layer
while the Hardware Device Module (HDM) sits between the I2O
communications layer and the hardware. The HDM may well run on a
dedicated processor (IOP).
-->
「I2O(Intelligent Input/Output)仕様は、インテリジェントな入出力のための
標準的なアーキテクチャで、制御されるデバイスやホストのオペレーティング
システム(OS)から独立しています」(<ulink 
url="http://www.i2osig.org"><literal>www.i2osig.org</literal></ulink>から
引用)。
I2O は「分割ドライバ」モデルを定義しており、それによると 
OS Services Module(OSM)が、ホスト OS のデバイスインタフェースと I2O 
コミュニケーション層の間に入り、一方 Hardware Device Module(HDM)が、I2O 
コミュニケーション層とハードウェアの間に入ります。HDM は、恐らく専用
プロセッサ(IOP)上で動作するでしょう。
</para>
</formalpara>

</appendix>

<appendix id="changes">
      <!--
      <title>Changes between lk 2.2 and (during) 2.4</title>
      -->
      <title>Linux カーネル 2.2 と 現状のカーネル 2.4 間の変更</title>
<para>
<!--
Significant work has been done to change the single SCSI command queue
used in lk 2.2 to one command queue per device. To make the SCSI subsystem
more SMP friendly the granularity of the locks is much finer grained. In
lk 2.2 the whole subsystem essentially used one lock.
-->
特筆すべき作業としては、Linux カーネル 2.2 では SCSI コマンドキューがひとつ
しかなかったのに対し、デバイスごとにひとつのキューが使えるようになりました。
SCSI サブシステムが SMP により親和性が高くなるように、ロックの粒度がさらに
細かくなっています。linux カーネル 2.2 では、基本的にサブシステム全体が 1 つ
のロックを使っていました。
</para>
<para>
<!--
Even though it is not part of the SCSI subsystem, the inclusion of devfs
solves many SCSI device addressing problems that existed in the past.
Associated with devfs but very useful even in its absence is the
"scsihosts" kernel boot time (and module load time) option. This option
allows users to have some control over the ordering of multiple SCSI hosts.
-->
SCSI サブシステムの一部ではありませんが、devfs が対応することで、SCSI 
デバイスが以前抱えていたアドレス付け問題が多数解決します。
devfs に関連して、devfs が無い場合にとても便利なのが、カーネルブート時
(およびモジュールロード時)の「scsihosts」オプションです。ユーザはこの
オプションによって、複数の SCSI ホストの順序付けを制御できます。
</para>
<para>
<!--
This appendix is difficult to maintain since features and drivers that
have proven useful in lk 2.4 (and its development tree) have tended to
be back ported into the higher release numbers of the lk 2.2 series.
-->
Linux カーネル 2.4(とその開発ブランチ)で効果が明らかになった機能や
ドライバは、Linux カーネル 2.2 系の新しいリリースにバックポートされる
傾向にありますので、この付録の更新は容易ではありません。
</para>
<para>
<!--
Currently (lk 2.4.2) support for MO devices is broken. Old DOS file
systems with a block size of 2048 bytes also have been reported as broken.
The problem seems to arise with media that have a physical block size
larger than the 1 KB logical block size used by the block subsystem.
Only the sd driver has this problem (luckily not the sr driver in
which 2048 byte sectors are the norm).
-->
現在(Linux カーネル 2.4.2)、MO デバイスのサポートがおかしくなっています。
ブロックサイズが 2048 バイトである古い DOS ファイル・システムもおかしい
との報告が上がっています。
ブロックサブシステムが使用している 1 KB の論理ブロックサイズよりも、物理
ブロックサイズが大きいメディアで起こる問題のようです。
sd ドライバにだけ問題があります(幸いなことに、2048バイトのセクタが標準である
sr ドライバは、問題ありません)。
</para>

<sect1 id="chgml">
      <!--
  		<title>Mid level changes</title>
  		-->
  		<title>中間レベルの変更</title>
<para>
<programlisting>
SCSI_IOCTL_GET_IDLUN    {ioctl, changed}
</programlisting>
</para>
</sect1>

<sect1 id="chgsd">
      <!--
  		<title>sd changes</title>
  		-->
  		<title>sd の変更</title>
<para>
<programlisting>
HDIO_GETGEO_BIG         {ioctl, new}
 <!-- flagged _not_ added:  SCSI_EMULATED_HOST      {ioctl, new} -->
</programlisting>
</para>
</sect1>

<sect1 id="chgsr">
      <!--
  		<title>sr changes</title>
  		-->
  		<title>sr の変更</title>
<para>
<!--
No sr changes reported. As a related matter, the "hdx=scsi" kernel boot 
option has been added. See <xref linkend="sratapi"/> for more details.
-->
sr の変更は報告されていません。関連事項として、「hdx=scsi」というカーネル
ブート時のオプションが追加されています。詳細は<xref linkend="sratapi"/>
を参照してください。
</para>
</sect1>

<sect1 id="chgst">
  		<!--
      <title>st changes</title>
  		-->
      <title>st の変更</title>
<para>
<!--
No interface changes. In lk 2.2 the maximum number of extra tape devices
that could be added after boot time was limited to 3. This limitation
has been removed (leaving a maximum of 32 tape devices as noted earlier).
-->
インタフェースに変更はありません。Linux カーネル 2.2 では、ブート後に追加
できる最大テープ デバイス接続数が 3 に制限されていました。この制限は
無くなりました(先に述べた通り、テープデバイスの最大数は 32 個のまま)。
</para>
<para>
<!--
A variant st driver called "osst" to handle early model OnStream tape
drives has been added in lk 2.4 .
-->
st ドライバの仲間である「osst」は、OnStream の初期モデルのテープドライブ
を対象にしており、Linux カーネル 2.4 で追加されました。
</para>
</sect1>

<sect1 id="chgsg">
  		<!--
      <title>sg changes</title>
  		-->
      <title>sg の変更</title>
<para>
<!--
The main change is the addition of a new interface structure called 
"sg_io_hdr". The existing interface structure (called "sg_header") was found
to be inflexible requiring the concatenation of raw data together with
meta-data in the read() and write() commands.
-->
主な変更は、「sg_io_hdr」という新しいインタフェース構造体の追加です。
これまでの(「sg_header」と呼ばれていた)インタフェース構造体は、read() と 
wite() コマンドにおいて、raw データとメタデータを連結する必要があった点、
柔軟さに欠けていました。
<programlisting>
<!--
sg_io_hdr          {new interface structure}
SG_IO              {new ioctl}
direct IO          {present but commented out, see ALLOW_DIO}
procfs output      {new information in /proc/scsi/sg directory}
boot/module parameters  {new}
-->
sg_io_hdr          {新しいインタフェース構造体}
SG_IO              {新しい ioctl}
direct IO          {存在しているが、コメントアウトしてある。ALLOW_DIOを参照}
procfs output      {/proc/scsi/sg directory の新しい情報}
boot/module parameters  {新規}
</programlisting>
</para>
<para>
<!--
Up to 64 bytes of sense data can be obtained from the sg_io_hdr interface
structure. Also a residual count associated with the data transfer is
available (if the lower level driver supports it, if not the residual count
will be 0).
-->
sg_io_hdr インタフェース構造体からは、64 バイトまでのセンスデータが取得
できます。またデータ転送における残り分の数も取得できるようになっています
(低レベルのドライバがサポートし、残り分が 0 でなければ)。
</para>
</sect1>
<sect1 id="chg24">
  		<!--
      <title>Changes during the lk 2.4 series</title>
  		-->
      <title>Linux カーネル 2.4 系での変更</title>
<para>
<!--
Even though the lk 2.4 production series is meant to be "stable" there
have been a significant number of changes as well as bug fixes. The 
following list does not include changes to the lower level (adapter)
drivers. Each item of the list is prefixed by the kernel version that 
it was introduced.
-->
Linux カーネル 2.4 系は「安定版」ですが、バグフィックスだけでなく、かなりの
変更があります。下記のリストには低レベル(アダプタ)の変更は入っていません。
リストそれぞれの項目の先頭部分は、その変更がアナウンスされたカーネル
バージョンです。
<footnote><para>
<!--
This list has been compiled from the official 2.4 series kernels released
at <ulink url="http://www.kernel.org"> www.kernel.org</ulink>. Distributions
are free to tailor the official kernels and this may impact what is
supported (or changed) in the SCSI subsystem. For example this machine
reports this kernel: "2.4.18-27.8.0". So that is roughly based on the
official 2.4.18 kernel which the vendor has "modded" 27 times for the
"8.0" level of their distribution. As an example of the type of changes,
the aic7xxx driver in the official 2.4.18 does not support Adaptec's
Ultra 320 series of PCI adapters; however that vendor's version does.
-->
このリストは<ulink url="http://www.kernel.org"> www.kernel.org</ulink>に
ある公式のカーネル 2.4 系リリースから集めたものです。
ディストリビューションは独立して公式のカーネルをいじっていますので、SCSI 
サブシステムのサポート(もしくは変更)にも影響が出るでしょう。
例えばこのマシンではカーネルが「2.4.18-27.8.0」となっています。
おそらく公式のカーネル 2.4.18 を元にしていて、ディストリビューションの「8.0」
版のために、ベンダーが 27 回に渡って修正をかけたということでしょう。
変更の種類の一例として、公式の 2.4.18 に入っている aic7xxx ドライバは
Adaptec の Ultra 320 シリーズの PCI アダプタをサポートしていませんが、
ベンダーのバージョンではサポートしています。
</para></footnote>
<itemizedlist>
<listitem><para>
<!--
[2.4.4] added the SCSI_IOCTL_GET_PCI ioctl(),
-->
[2.4.4] SCSI_IOCTL_GET_PCI ioctl() 追加。
</para></listitem>
<listitem><para>
<!--
[2.4.7] the "lun" bits (3 bits representing lun values 0 through 7
in the SCSI 1 and SCSI 2 standards) are no longer masked into the second
byte of SCSI commands if the INQUIRY for that devices shows a SCSI level
greater than SCSI_2,
-->
[2.4.7] デバイスへの INQUIRY で SCSI レベルが SCSI_2 より上位であると
わかった場合、今後「LUN」ビット(SCSI 1 と SCSI 2 規格では 3 ビットで
LUN の値は 0 から 7) による SCSI コマンドの 2 バイト目のマスクは行わない。
</para></listitem>
<listitem><para>
<!--
[2.4.7] the max_scsi_luns kernel (and module scsi_mod) option 
previously could be 1 to 7. Now the upper value can be large. [The scan 
algorithms are still doing a sequential scan rather than using REPORT_LUNS.]
-->
[2.4.7] カーネル(と scsi_mod モジュール)オプション max_scsi_luns が取る値は 
1 から 7 だったが、より大きな値がとれるようになった。(スキャンアルゴリズムは、
まだ REPORT_LUNS を利用せずにシーケンシャルスキャンを行う)。
</para></listitem>
<listitem><para>
<!--
[2.4.7] both scsi_unregister_host() and scsi_unregister_module() now 
return an int (previously they were void functions). They return 0 for 
success, -1 for failure (typically busy),
-->
[2.4.7] scsi_unregister_host() と scsi_unregister_module() が intを返す
ようになった(以前は、void を返した)。0 が成功で、-1 が失敗(たいていは busy 
状態)。
</para></listitem>
<listitem><para>
<!--
[2.4.7] the upper level drivers now report the correct scsi device
name when they are attached. [The log messages that started with 
"Detected ..." previously sometimes reported the wrong device (e.g. sdc 
rather than sdb).] Kernel boot up messages will now show SCSI devices
as "Attached ...",
-->
[2.4.7] 高レベルのドライバが、接続している SCSI デバイス名を正しく返すように
なった。(「Detected ...」ではじまるログのメッセージが、時としておかしな
デバイス名を返していた(例えば sdb ではなく sdc というように))。カーネル
のブート時のメッセージに「Attached ...」のように、SCSI デバイスが出るように
なった。
</para></listitem>
<listitem><para>
<!--
[2.4.7] 'max_sectors' was added to the Scsi_Host structure,
-->
[2.4.7] Scsi_Host 構造体に「max_sectors」が追加された。
</para></listitem>
<listitem><para>
<!--
[2.4.8] some mid level logic was altered to retry commands if the
sense buffer indicates that logical unit is becoming ready [ASC=4, ASQ=1],
-->
[2.4.8] 中間レベルのロジックが変更され、センスバッファで論理ユニットが
準備完了(ASC=4, ASQ=1)を示すと、コマンドをリトライするようになった。
</para></listitem>
<listitem><para>
<!--
[2.4.9] a major st update, 
-->
[2.4.9] st のメジャーアップデート。
</para></listitem>
<listitem><para>
<!--
[2.4.9] mid level changed to retry
commands if lower level (adapter) driver returned DID_RESET,
-->
[2.4.9] 低レベル(アダプタ)が DID_RESET を返すと
コマンドをリトライするよう、中間レベルが変更された。
</para></listitem>
<listitem><para>
<!--
[2.4.10] original result (including SCSI status) saved when mid level
issues a REQUEST SENSE so it can be restored afterwards,
-->
[2.4.10] 中間レベルが REQUEST SENSE を発行すると、元々の結果(SCSI の状態を
含む)が保存されるようになり、後で復元できるようになった。
</para></listitem>
<listitem><para>
<!--
[2.4.10] added BLKGETSIZE64, BLKBSZSET and BLKBSZGET ioctls to sd + sr,
-->
[2.4.10] BLKGETSIZE64、BLKBSZSET、BLKBSZGET 各 ioctl が sd と sr へ追加された。
</para></listitem>
<listitem><para>
<!--
[2.4.10] sg update that fixes generic_unplug_device() race + bumps
access_count on opens (and decrements on releases),
-->
[2.4.10] sg の競合が修正され、open 時に access_count を増加(および解放時に
減少)するようになった。
</para></listitem>
<listitem><para>
<!--
[2.4.11] added MODULE_LICENSE macro in most drivers, mostly
MODULE_LICENSE("GPL"),
-->
[2.4.11] MODULE_LICENSE("GPL")であるほとんどのドライバへ MODULE_LICENSE 
マクロを追加。
</para></listitem>
<listitem><para>
<!--
[2.4.11] scsi_pid bumped for each command (why?),
-->
[2.4.11] 各コマンドの scsi_pid が 1 増えた(なんで？)。
</para></listitem>
<listitem><para>
<!--
[2.4.11] st update to bump access_count. Now all upper level drivers
increment access_count on opens and decrement it on releases,
-->
st が更新され、access_count が増えた。これで高レベルのドライバは、
すべて open 時に access_count を増やし、解放時に減らす。
</para></listitem>
<listitem><para>
<!--
[2.4.13] scatterlist structure grows (alt_address is removed, page and
offset added),
-->
[2.4.13] scatterlist 構造体の拡張(alt_address が削除され、page と offset が
追加)。
</para></listitem>
<listitem><para>
<!--
[2.4.13] don't probe luns > 7 for target &lt;= SCSI_2 ,
-->
[2.4.13] ターゲット &lt;= SCSI_2 なら、8 以上の LUN はスキャンしない。
</para></listitem>
<listitem><para>
<!--
[2.4.14] fine tuning (bug fixes) associated with scatterlist structure
changes [it broke st ?],
-->
[2.4.14] scatterlist 構造体の変更に関したチューニング(バグ修正)(st が壊れた？)
</para></listitem>
<listitem><para>
<!--
[2.4.15] 16 byte SCSI commands permitted [MAX_COMMAND_SIZE changes from
12 to 16]. HBA driver must set Scsi_Host::max_cmd_len to 16 for
mid level to forward 16 byte SCSI commands,
-->
[2.4.15] 16 バイトの SCSI コマンドを許可(MAX_COMMAND_SIZE が 12 から 16 
に変更)。中間レベルが 16 バイトの SCSI コマンドを扱うには、HBA ドライバは 
Scsi_Host::max_cmd_len を 16 に設定する必要がある。
</para></listitem>
<listitem><para>
<!--
[2.4.15] BLKGETSIZE + BLKGETSIZE64 ioctl() implementations moved out of
SCSI subsystem (and into block subsystem),
-->
[2.4.15] SCSI サブシステムから、BLKGETSIZE、BLKGETSIZE64 各 ioctl()の実装
が削除された(ブロックサブシステムに移動)。
</para></listitem>
<listitem><para>
<!--
[2.4.15] large st update,
-->
[2.4.15] st の大幅なアップデート。
</para></listitem>
<listitem><para>
<!--
[2.4.15] lk 2.5.0 forks off so lk2.4.15==lk2.5.0 .
-->
[2.4.15] Linux カーネル 2.5.0 が分岐し、Linux カーネル 2.4.15 == Linux 
カーネル 2.5.0 になる。
</para></listitem>
<listitem><para>
<!--
[2.4.17] add generic_unplug_device() call to scsi_wait_req(). This stops
long waits in SCSI_IOCTL_SEND_COMMAND.
-->
[2.4.17] scsi_wait_req()に generic_unplug_device()が追加。これで 
SCSI_IOCTL_SEND_COMMAND における長い wait が解消。
</para></listitem>
<listitem><para>
<!--
[2.4.17] fix device scanning bug where, in some cases, the scsi_level
(i.e. SCSI standard adherence) was misplaced.
-->
[2.4.17] デバイスをスキャンする際に scsi_level(つまり SCSI 規格への対応レベル)
を間違えるバグがあった。
</para></listitem>
<listitem><para>
<!--
[2.4.17] major sg driver update, add mmap()-ed IO
-->
[2.4.17] sg ドライバの大幅な更新。mmap()-ed IO の追加。
</para></listitem>
<listitem><para>
<!--
[2.4.18] permit upper level driver "init()" functions (e.g. sd_init() )
to fail gracefully. [Add Scsi_Device::detected and scsi_unregister_module() .]
-->
[2.4.18] 高レベルのドライバが、「init()」関数を許可(例えば sd_init())を、
きちんと手続きを踏んだ上で失敗できるようになった。(Scsi_Device::detected と 
scsi_unregister_module()が追加)。
</para></listitem>
<listitem><para>
<!--
[2.4.18] Fix for clustering (SCSI commands) on MO devices.
-->
[2.4.18] MO デバイスでの SCSI コマンドのクラスタリングを修正。
</para></listitem>
<listitem><para>
<!--
[2.4.18] st driver update (compression algorithms).
-->
[2.4.18] st ドライバの更新(圧縮アルゴリズム)。
</para></listitem>
<listitem><para>
<!--
[2.4.18] update Documentation/scsi.txt and scsi-generic.txt .
-->
[2.4.18] Documentation/scsi.txt と scsi-generic.txt の更新。
</para></listitem>
<listitem><para>
<!--
[2.4.18] Revamp scsi_debug driver .
-->
[2.4.18] scsi_debug ドライバの修正。
</para></listitem>
<listitem><para>
<!--
[2.4.19] Scsi reservation and reset capability added. Reservations allow
multiple machines to share the same device (via a reserve/release mechanism).
Scsi reset (via sg) is needed to "break" a reservation held by a
non-responding machine.
-->
[2.4.19] SCSI の予約機能とリセット機能を追加。予約によって、複数マシンが同じ
デバイスを(予約・解放機構により)共有できるようになった。
予約しているのに反応の無いマシンを「中断」するには、(sg 経由の)SCSI をリセット
が必要とされる。
</para></listitem>
<listitem><para>
<!--
[2.4.19] Introduce BLIST_LARGELUN to handle LUNs larger than 7 despite
reporting SCSI 2.
-->
[2.4.19] BLIST_LARGELUN を導入し、SCSI 2 と認識しても 7 より大きい 
LUN を扱うようにした。
</para></listitem>
<listitem><para>
<!--
[2.4.19] Change sd and sr so RECOVERED_ERROR is not treated as a hard 
error. Send warning to log/console.
-->
[2.4.19] sd と sr を変更し、RECOVERED_ERROR をハードエラーと
扱わないようにした。ログもしくはコンソールに警告を送る。
</para></listitem>
<listitem><para>
<!--
[2.4.19] Zero out sg's buffers before use. [Sg version upgraded from 
3.1.22 to 3.1.24 but this is not reflected in sg.h (supeficial).]
-->
[2.4.19] 使用前に sg のバッファをゼロに設定する。(sg のバージョンが 
3.1.22 から 3.1.24 へアップグレードしたが、sg.h には(表面的には)反映されて
いない)。
</para></listitem>
<listitem><para>
<!--
[2.4.20] Support for highmem I/O added. Used by aic7xxx,
3w-xxxx, esp, megaraid, qlogicfc and sym53c8xx_2 LLDs.
-->
[2.4.20] ハイメモリ(HIGHMEM)入出力のサポート追加。aic7xxx や 3w-xxxx、esp、
megaraid、qlogicfc、sym53c8xx_2 LLD。
</para></listitem>
<listitem><para>
<!--
[2.4.20] "blocking_open" boot time, module load time parameter added to st.
-->
[2.4.20] st にブート時及びモジュールロード時の「blocking_open」パラメタを追加。
</para></listitem>
</itemizedlist>
</para>
</sect1>
</appendix>

<appendix id="trouble">
  		<!--
      <title>Troubleshooting</title>
  		-->
      <title>トラブルシューティング</title>
<para>
<!--
Many SCSI problems are caused by cabling and (lack of, or inappropriate)
termination. This often results in repeated SCSI bus resets, parity
or CRC errors and sometimes reduced transfer speeds. There is a good
SCSI termination tutorial at this site:
<ulink url="http://www.scsita.org/aboutscsi/SCSI_Termination_Tutorial.html">
www.scsita.org/aboutscsi/SCSI_Termination_Tutorial.html</ulink>. There is
other useful SCSI information at that site (see <link linkend="W9">W9</link>).
-->
SCSI の問題の多くは、ケーブルの取り回しと終端処理(がされていない、もしくは
不適切)が原因です。これによって SCSI バスのリセットが発生し、パリティ
や CRC エラーが起こり、時には転送速度が低下します。SCSI の終端の方法について
は、素晴らしいチュートリアルが次のサイトにあります。
<ulink url="http://www.scsita.org/aboutscsi/SCSI_Termination_Tutorial.html">
www.scsita.org/aboutscsi/SCSI_Termination_Tutorial.html</ulink>。
そのサイトには他にも、ためになる SCSI の情報があります
(<link linkend="W9">W9</link>を参照)。
</para>
<para>
<!--
There is also a SCSI "faq" site (see <link linkend="W10">W10</link>)
that addresses many configuration and troubleshooting issues. Although
the main focus of this site is Windows (and its ASPI interface), much
is relevant to SCSI in Linux and other Unix implementations.
-->
SCSI の「FAQ」サイトもあります(<link linkend="W10">W10</link>参照)。
設定とトラブルシューティングをいろいろと扱っています。このサイトの焦点は
Windows(とその ASPI インタフェース)にありますが、多くは Linux や他の Unix の
実装における SCSI にも関連しています。
</para>
<para>
<!--
When it looks like something has partially locked up the system, the
<command>ps</command> command can be useful for finding out what may be
causing the problem. The following options may be useful for identifying what
part of the kernel may be causing the problem. This information could be
forwarded to the maintainers.
-->
システムのどこかが固ったように見える時、問題の原因を見つけ出すには、
<command>ps</command> コマンドが役立ちます。
下記のオプションは、カーネルのどの部分が問題を起こしているのかを特定するのに
便利です。この情報をメンテナーに送ってみてください。
<programlisting>
ps -eo cmd,wchan
ps -eo fname,tty,pid,stat,pcpu,wchan
ps -eo pid,stat,pcpu,nwchan,wchan=WIDE-WCHAN-COLUMN -o args
</programlisting>
<!--
The most interesting option for finding the location of the "hang" is
"wchan". If this is a kernel address then <command>ps</command> will
use <filename>/proc/ksyms</filename> to find the nearest symbolic
location. The "nwchan" option outputs the numerical address of the "hang".
-->
「ハング」している所を見つけ出すのに最も大事なオプションは、「wchan」
です。これがカーネルのアドレスならば、<command>ps</command> は 
<filename>/proc/ksyms</filename> を使って、最も近いシンボルの位置を見つます。
「nwchan」オプションは、数字で現した「ハング」したアドレスです。
</para>
<para>
<!--
If the system is not responding to keystrokes, then &lt;Alt+ScrollLock>
in text mode should output a stack trace while &lt;Ctrl+ScrollLock>
should output a list of all processes. If the log is still working, the
output will be sent there as well as appearing on the console.
-->
キーを打ってもシステムが反応しない場合、テキストモードで &lt;Alt+ScrollLock> 
とすればスタックトレースが出力され、&lt;Ctrl+ScrollLock> とすればすべての
プロセスの一覧が出力されるはずです。ログ機能がまだ動いていれば、出力はログ
とコンソールにも送られます。
</para>
<para>
<!--
If the kernel has been built with the CONFIG_MAGIC_SYSRQ, then in text
mode &lt;Alt+SysRq+H> will list available commands. Of these &lt;Alt+SysRq+S>
is useful for doing an emergency sync while &lt;Alt+SysRq+U> will remount
file systems in read only mode. After that &lt;Alt+SysRq+B> to reboot the
machine might be your next move.
-->
CONFIG_MAGIC_SYSRQ を設定してカーネルを構築してあれば、テキストモード
で &lt;Alt+SysRq+H> を押すと、使用できるコマンドがリストされます。
&lt;Alt+SysRq+S> は、緊急時に sync する場合に役立ち、&lt;Alt+SysRq+U> は、
リードオンリーでファイルシステムをマウントし直すのに便利です。これを行ったら、
次は &lt;Alt+SysRq+B> でマシンをリブートすることになるでしょう。
</para>
</appendix>

<appendix id="perform">
  		<!--
      <title>Performance, Test and Debugging tools</title>
  		-->
      <title>パフォーマンス、テスト、デバッグ用のツール</title>
<formalpara><title>scu</title>
<para>
<!--
The SCSI Command Utility (SCU) implements various SCSI commands necessary
for normal maintenance and diagnostics of SCSI peripherals. Some of its
features include: formatting, scanning for (and reassigning) bad blocks,
downloading new firmware, executing diagnostics and obtaining
performance information. It is available on several Unix platforms
(and NT), however it is only currently available in binary form. See
<ulink url="http://www.bit-net.com/~rmiller/scu.html">
www.bit-net.com/~rmiller/scu.html</ulink> for more details.
-->
SCSI Command Utility(SCU)には、SCSI 機器の日常のメンテナンスや診断に必要な
様々な SCSI コマンドが用意されています。含まれている機能は、フォーマット、
不良ブロックのスキャン(とブロックの再配置)、新しいファームウェアの
ダウンロード、診断の実行、パフォーマンス情報の取得などがあります。Unix プラット
フォーム(と NT)のいくつかで利用可能ですが、現状ではバイナリ形式のみの提供
です。詳細は 
<ulink url="http://www.bit-net.com/~rmiller/scu.html">
www.bit-net.com/~rmiller/scu.html</ulink>を見てください。
</para>
</formalpara>
<formalpara><title>dd</title>
<para>
<!--
Very useful for testing the streaming performance of disks and cdroms/dvds.
See <command>man dd</command> for more details. Here is an example for
timing how long a disk takes to read 1 GB (10**9 bytes) starting from block 0:
-->
ディスクや CD-ROM、DVD で、ストリーミング性能のテストにとても便利です。
詳細は <command>man dd</command> してみてください。例として、0 ブロックから
はじまる 1 GB(10**9 バイト)のデータをディスクから読み取るのにどのくらい
かかるのか調べる例を挙げておきます。
<programlisting>
$ time dd if=/dev/sda of=/dev/null bs=512 count=1953126
</programlisting>
<!--
If the raw device <filename>/dev/raw/raw1</filename> is bound to
<filename>/dev/sda</filename> then the above line is equivalent to:
-->
<filename>/dev/sda</filename> の raw デバイスが <filename>/dev/raw/raw1
</filename> なら、上記の行は下記と等しくなります。
<programlisting>
$ time dd if=/dev/raw/raw1 of=/dev/null bs=512 count=1953126
</programlisting>
<!--
This may be slower than expected since one 512 byte sector is being read
at a time. Changing the last 2 arguments to "bs=8k count=122071" should
give better timings for the "raw" dd.
-->
一度に 1 セクタ 512 バイトを読んでいるので、期待していた程速くない
かもしれません。dd の最後 2 つの引数を「bs=8k count=122071」に変更すれば、
「raw」への dd はより高速になるはずです。
</para>
</formalpara>
<formalpara><title>dt</title>
<para>
<!--
The Data Test (DT) program is modelled on dd's syntax but dt can do a
lot more than sequential copies. It is a comprehensive data test program
for SCSI devices such as disks, tapes and cdrom/dvds. It is available on
several Unix platforms (and NT), and its source is available (unlike its
stable mate "scu" discussed earlier). See 
<ulink url="http://www.bit-net.com/~rmiller/dt.html">
www.bit-net.com/~rmiller/dt.html</ulink> for more details.
-->
Data Test(DT)プログラムは、dd の書式を雛形にしています。しかし、dt には
シーケンシャルなコピーの他にも、いろいろな機能があります。ディスクやテープ、
CD-ROM、DVD のような SCSI デバイス向けの総合的なデータテストプログラムです。
Unix プラットフォーム(と NT)のいくつかで利用が可能で、ソースも利用可能です
(これが前出の「scu」と異なります)。
<ulink url="http://www.bit-net.com/~rmiller/dt.html">
www.bit-net.com/~rmiller/dt.html</ulink> に詳しい情報があります。
</para>
</formalpara>
<formalpara><title>lmdd</title>
<para>
<!--
This command is part of the lmbench suite of programs and is a variant of the
<command>dd</command> command. It has been tailored for IO measurements
and outputs timing and throughput numbers on completion. Hence the
<command>time</command> command and a calculator are not needed.
-->
このコマンドは、lmbench に入っているプログラムの 1 つで、<command>dd</command> 
コマンドと同系列のプログラムです。入出力の測定用になっていて、完了時に
かかった時間と転送量を出力します。つまり <command>time</command> コマンドと
電卓は必要なくなります。
</para>
</formalpara>
<formalpara><title>blockdev</title>
<para>
<!--
Fetches the sector size, the number of sectors and read ahead status
of a block device (typically a disk). Can also be used to flush buffers
and reread the partition table. See <command>man blockdev</command>.
-->
ブロックデバイス(通常はディスク)のセクタサイズとセクタ数、先読み状態
を取得します。バッファをフラッシュするのにも利用でき、パーティション
テーブルの再読み込みも可能です。<command>man blockdev</command> を参照して
ください。
</para>
</formalpara>
<formalpara><title>sg_dd</title>
<para>
<!--
This command is part of the sg_utils package (see 
<link linkend="W4">W4</link>) and is another variant of the
<command>dd</command> command in which either the input and/or
output file is a sg or a raw device. The block size argument ("bs") must
match that of the physical device in question. The "skip" and "seek" arguments
can be up to 2**31 - 1 on a 32 bit architecture allowing 1TB disks to be
accessed (2G * 512). The Linux system command llseek() is used to seek with
a 64 bit file read/write offset. The <command>lmdd</command> does not
handle the > 2GB case and the <command>dd</command> command gets creative
with multiple relative seeks. <command>sg_dd</command> has
a "bpt" (blocks per transfer) argument that controls the number of blocks
read or written in each IO transaction.
-->
このコマンドは sg_utils パッケージの一部(<link linkend="W4">W4</link>を参照)
です。<command>dd</command> コマンドの仲間で、入出力両方もしくはいずれか
一方を sg もしくは raw デバイスに対して行います。ブロックサイズの引数(「bs」)
は、その物理デバイスのものと合致している必要があります。引数の「skip」と「seek」
は、32 ビットアーキテクチャでは 2**31 - 1 まで設定でき、1 TB(2G * 512)の
ディスクにアクセスできます。64 ビットのファイルの読み書きオフセットのシーク
には、Linux のシステムコマンド llseek() が用いられます。<command>lmdd</command> 
は、2 GB より大きい場合は扱えませんし、<command>dd</command> コマンドは複数
の相対的な seek を行うとまともな結果は返りません。<command>sg_dd</command>
には、「bpt」(転送当たりのブロック数)引数があり、入出力それぞれにおける読み
書きのブロック数を制御します。
</para>
</formalpara>
<para>
<!--
There are other programs in the sg_utils package to scan the SCSI bus
(<command>sg_scan</command> and <command>sg_map</command>), to measure
SCSI bus throughput (<command>sg_rbuf</command> and <command>sg_turs
</command>), show data from the SCSI inquiry command
(<command>sg_inq</command>) and spin up (or down) media
(<command>sg_start</command>).
-->
sg_utils パッケージにはその他にもプログラムがあります。SCSI バスをスキャン
する(<command>sg_scan</command> と <command>sg_map</command>)、SCSI バスの
転送量を計測する(<command>sg_rbuf</command> と <command>sg_turs</command>)、
SCSI の INQUIRY コマンドからのデータを表示する(<command>sg_inq</command>)、
媒体をスピンアップしたりダウンしたりする(<command>sg_start</command>)が
あります。
</para>
<formalpara><title>dd_rescue + scsiinfo</title>
<para>
<!--
This dd variant is designed to rescue damaged media such as SCSI (or IDE)
disks and CDROMs (see <link linkend="W6">W6</link>). The <command>
scsiinfo</command> utility for displaying and changing mode page
information is also at that site.
-->
この dd 系コマンドは、SCSI(もしくは IDE)ディスクや CD-ROM
(<link linkend="W6">W6</link>を参照)といった媒体を障害から復旧するために
作られました。<command>scsiinfo</command> は、モードページ情報を表示
したり変更したりするユーティリティで、同じ所から入手できます。
</para>
</formalpara>
<formalpara><title>sard</title>
<para>
<!--
This utility is modelled on System V Release 4's <command>sar -d</command> for
producing IO statistics for mounted devices and partitions. It has been
developed by Stephen Tweedie and includes the sard utility and a required
kernel patch which expands the output of <filename>/proc/partitions</filename>
. It can be found at 
<ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/profiling">
ftp.uk.linux.org/pub/linux/sct/fs/profiling</ulink>. It collects statistics
at a relatively low level (e.g. SCSI mid level) compared to programs
like <command>vmstat</command> (see "man vmstat").
-->
このユーティリティは、System V Release 4 の <command>sar -d</command>を
参考にし、マウントしているデバイスとパーティションの入出力状態を見られる
ようにします。Stephen Tweedie 氏が作成し、sard ユーティリティが入って
います。
<filename>/proc/partitions</filename> に出力するよう拡張するにはカーネル
パッチが必要です。
<ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/profiling">
ftp.uk.linux.org/pub/linux/sct/fs/profiling</ulink>から入手できます。
<command>vmstat</command>(「man vmstat」を参照)のようなプログラム
と比べて、比較的低レベル(例えば SCSI の中間レベル)の状態を収集します。
</para>
</formalpara>

</appendix>

<appendix id="compileopt">
  		<!--
      <title>Compile options and System calls including ioctls</title>
  		-->
      <title>コンパイルオプションとシステムコール(ioctls を含む)
  		</title>
<para>
<!--
The compile options in this appendix are those which a system administrator
might conceivably want to change. Naturally the defaults are chosen so the
vast majority of users will not need to modify anything. In some cases setting
kernel build time options, kernel boot time parameters or module load
parameters has the same effect as changing a driver compile time option.
-->
この付録では、コンパイル時のオプションのうち、システム管理者が変更したくなる
であろうものについて述べます。デフォルトではユーザの期待通りの選択がされて
いるので、大多数は何も変更する必要はないでしょう。カーネル構築時オプションの
設定によっては、カーネルブート時のパラメタとモジュールロード時のパラメタが、
ドライバのコンパイル時オプションと同じ効果を持つ場合もあります。
</para>
<para>
<!--
System calls act as the interface between application programs and the
kernel and its drivers. In the case of the layered driver architecture that
the SCSI subsystem uses, the upper layer drivers handle most of the
system calls.
-->
システムコールは、アプリケーションプログラムとカーネルとそのドライバ間の
インタフェースとして動作します。SCSI サブシステムが採用しているレイヤ化
されたドライバのアーキテクチャでは、システムコールの大半は高レベルの
ドライバが処理しています。
</para>
<para>
<!--
The SCSI subsystem has a "bubble down" ioctl structure. First the upper level
driver associated with the open file descriptor attempts to decode the ioctl.
If it doesn't recognize it then the ioctl is passed down to the mid level. If
the mid level doesn't recognize it then the ioctl is passed down to the lower
level driver associated with the file descriptor. If the lower level driver
doesn't recognize it then a EINVAL error is generated.
-->
SCSI サブシステムは「下層に通知していく」ioctl 構造になっています。まず
オープンしているファイルディスクリプタに対応した高レベルのドライバが 
ioctl を解釈しようとします。
それができないと、ioctl は中間レベルに渡ります。中間レベルでも駄目な場合
、ファイルディスクリプタに対応した低レベルのドライバに渡ります。低レベルの
ドライバも駄目なら、EINVAL エラーが生じます。
</para>
<para>
<!--
Some ioctls are dispatched to related subsystems.
-->
関連しているサブシステムに処理を任せる ioctl もあります。
</para>

<sect1 id="coml">
  		<!--
      <title>Mid level</title>
  		-->
      <title>中間レベル</title>
<para>
<!--
The following header files in the kernel source are relevant to the mid
level:
-->
カーネルソースにある下記のヘッダファイルは、中間レベルに関連しています。
<programlisting>
        /usr/src/linux/include/scsi/scsi.h
        /usr/src/linux/include/scsi/scsi_ioctl.h
</programlisting>
</para>
<para>
<!--
These files are meant for applications to use (other than parts in
a __KERNEL__ conditional compilation block). They may also be found in
/usr/include/scsi directory but it is best not to trust these versions as
they are maintained with the glibc library and may lag the kernel version
being used. Usually in Linux systems <filename>/usr/include/linux</filename>
can be relied upon to be a symbolic link to the kernel source's include
area (typically <filename>/usr/src/linux/include/linux</filename>). This
symbolic link can be used to include the correct <filename>scsi_ioctl.h
</filename> using the following trick: <filename>
#include &lt;linux/../scsi/scsi_ioctl.h></filename>
-->
これらのファイルは、アプリケーションから用いるためのものです(__KERNEL__ 条件
内部のコンパイルブロック以外の部分)。これらは /usr/include/scsi ディレクトリ
にもありますが、そちらは glibc ライブラリとともにメンテナンスされており、
カーネルのバージョンに追随していないので、信じない方が賢明です。
Linux システムでは、
<filename>/usr/include/linux</filename>がカーネルソースの include 領域
にシンボリックリンクされています(普通は、
<filename>/usr/src/linux/include/linux</filename>)。このシンボリックリンク
を使うと、<filename>#include &lt;linux/../scsi/scsi_ioctl.h></filename> という技によって、
正確な<filename>scsi_ioctl.h</filename>をインクルードできます。

</para>
<para>
<!--
This include file: <filename>/usr/src/linux/drivers/scsi/scsi.h</filename>
is the key internal header file for the SCSI subsystem. As such it will not
be discussed here other than to point out it has the same file name (but
it's in a different directory) as the include file mentioned at the beginning
of this section. This sometimes causes confusion.
-->
この <filename>/usr/src/linux/drivers/scsi/scsi.h</filename> は、SCSI サブ
システムの鍵となる内部ヘッダーファイルです。同名の(ただし、別ディレクトリに
存在する)ファイル名があり、それはこのセクションの最初で注目したファイルである
という点だけ指摘しておきます。これはときどき混乱の原因になります。
</para>
<para>
<!--
The mid level <filename>drivers/scsi/scsi_scan.c</filename> file
maintains an array of known SCSI devices with <emphasis>idiosyncrasies
</emphasis>. [This was known as the "black list" but that was considered
to judgmental.] The array is called "device_list". The various value are:
-->
中間レベルのファイル <filename>drivers/scsi/scsi_scan.c</filename> には、
既知の SCSI デバイスの多くが<emphasis>特徴ある記述方法で</emphasis>載って
います。(これは「ブラックリスト」として知られていましたが、あまりに断定的と
みなされていました)。この配列の名前は「デバイスリスト」です。
次のようにいろいろな値があります。
<itemizedlist>
<!--
<listitem><para>BLIST_NOLUN only probe lun 0</para></listitem>
<listitem><para>BLIST_FORCELUN force all 8 luns to be probed
</para></listitem>
<listitem><para>BLIST_BORKEN passes through broken flag to lower
level driver</para></listitem>
<listitem><para>BLIST_KEY sends magical MODE SENSE (pc=0x2e) to
unlock device</para></listitem>
<listitem><para>BLIST_SINGLELUN only allow IO on one lun at a time
</para></listitem>
<listitem><para>BLIST_NOTQ disable tagged queuing
</para></listitem>
<listitem><para>BLIST_SPARSELUN keep going after lun not found
</para></listitem>
<listitem><para>BLIST_MAX5LUN only probe up to lun 5
</para></listitem>
<listitem><para>BLIST_ISDISK override INQUIRY's type with disk (direct
access) type</para></listitem>
<listitem><para>BLIST_ISROM override INQUIRY's type with ROM
</para></listitem>
-->
<listitem><para>BLIST_NOLUN  LUN の 0 だけを検査する</para></listitem>
<listitem><para>BLIST_FORCELUN 8 つすべての LUN を強制的に検査
</para></listitem>
<listitem><para>BLIST_BORKEN 低レベルのドライバに 故障フラグを渡す
</para></listitem>
<listitem><para>BLIST_KEY ロックを外すドライバに即効果が出る MODE SENSE
(pc=0x2e)を送る
</para></listitem>
<listitem><para>BLIST_SINGLELUN は、一度に 1 つの LUN にしか入出力を許可
しない
</para></listitem>
<listitem><para>BLIST_NOTQ タグキューを無効
</para></listitem>
<listitem><para>BLIST_SPARSELUN LUN が見つからなくても動き続ける
</para></listitem>
<listitem><para>BLIST_MAX5LUN LUN を探るのを最大 5 まで
</para></listitem>
<listitem><para>BLIST_ISDISK INQUIRY タイプを強制的にディスク
(直接アクセス)に
</para></listitem>
<listitem><para>BLIST_ISROM INQUIRY タイプを 強制的に ROM に
</para></listitem>
</itemizedlist>
</para>

<sect2 id="comlco">
      <!--
  		<title>Mid level compile options</title>
  		-->
  		<title>中間レベルのコンパイルオプション</title>
<para>
<!--
None.
-->
ありません。
</para>
</sect2>

<sect2 id="comlio">
  		<!--
      <title>Mid level ioctls</title>
  		-->
      <title>中間レベルの ioctl</title>
<para>
<!--
See the following files:
-->
次のファイルを見てください。
<programlisting>
/usr/src/linux/include/scsi/scsi.h
</programlisting>
</para>
<para>
<!--
Note that the SCSI status constants defined in include/scsi/scsi.h are
shifted 1 bit right from the values in the SCSI standards:
-->
include/scsi/scsi.h で定義してある SCSI の状態定数は、SCSI 規格で定義
してある値に比べて、1 ビット右にシフトしている点に注意してください。
<programlisting>

<!--
scsi.h constant      value     SCSI 2 standard value
-->
scsi.h 定数           値       SCSI 2 規格の値
----------------------------------------------------
CHECK_CONDITION       0x1           0x2
CHECK_GOOD            0x2           0x4
BUSY                  0x4           0x8
....
</programlisting>
</para>
<para>
<!--
Summary of ioctl()s follow:
-->
ioctl()の概要は下記の通りです。
<programlisting>
SCSI_IOCTL_SEND_COMMAND
<!--
  This interface is deprecated - users should use
  the scsi generic (sg) interface instead, as this
  is a more flexible approach to performing
  generic SCSI commands on a device.

  The structure that we are passed should look like:
-->
  このインタフェースは旧方式です。かわりに汎用 SCSI(sg)インタフェース
  を利用してください。汎用 SCSI(sg)インタフェースを使った方が、デバイス
  をより柔軟に扱えます。

  これまで触れて来ませんでしたが、構造体は下記のようになります。
  struct sdata {
   <!--
   unsigned int inlen;     [i] Length of data written to device
   unsigned int outlen;    [i] Length of data read from device
   unsigned char cmd[x];   [i] SCSI command (6 &lt;= x &lt;= 16)
                           [o] Data read from device starts here
                           [o] On error, sense buffer starts here
   unsigned char wdata[y]; [i] Data written to device starts here
   -->
   unsigned int inlen;     [i] デバイスに書き込んだデータ長
   unsigned int outlen;    [i] デバイスから読み込んだデータ長
   unsigned char cmd[x];   [i] SCSI コマンド(6 &lt;= x &lt;= 16)
                           [o] デバイスから読み込んだデータはここから開始
                           [o] エラー時には、センスバッファはここから開始
   unsigned char wdata[y]; [i] デバイスに書き込んだデータはここから開始
  };
<!--
  Notes:
    -  The SCSI command length is determined by examining
       the 1st byte of the given command. There is no way
       to override this.
    -  Data transfers are limited to PAGE_SIZE (4K on
       i386, 8K on alpha).
    -  The length (x + y) must be at least OMAX_SB_LEN
       bytes long to accommodate the sense buffer when
       an error occurs. The sense buffer is truncated to
       OMAX_SB_LEN (16) bytes so that old code will not
       be surprised.
    -  If a Unix error occurs (e.g. ENOMEM) then the user
       will receive a negative return and the Unix error
       code in 'errno'. If the SCSI command succeeds then
       0 is returned. Positive numbers returned are the
       compacted SCSI error codes (4 bytes in one int)
       where the lowest byte is the SCSI status. See the
       drivers/scsi/scsi.h file for more information on this.
-->
  注意：
    ・SCSI コマンド長は、コマンドの最初のバイトでわかります。これを上書き
      する方法はありません。
    ・データ転送は、PAGE_SIZE(i386 で 4 K、alpha で 8 K)に制限されます。
    ・(x + y)の長さは、エラーが起こった時にセンスバッファ用に、
      最低 OMAX_SB_LEN バイトなければなりません。センスバッファは 
      OMAX_SB_LEN (16)バイトに縮められているので、古いコードでも支障はでません。
    ・Unix でエラーが発生した場合(例えば ENOMEM)、ユーザは負の返り値と
      「errno」にある Unix のエラーコードを受け取ります。
      SCSI コマンドが成功すると 0 が返ります。正の数を受け取ると、それは
      SCSI のエラーコードの集まりになっています(4 バイトが int ひとつにまとめ
      られている)。下位バイトが SCSI の状態を表しています。詳しい情報は
      drivers/scsi/scsi.h ファイルを見てください。
SCSI_IOCTL_GET_IDLUN
<!--
  This ioctl takes a pointer to a "struct scsi_idlun" object
  as its third argument. The "struct scsi_idlun" definition
  is found in &lt;scsi/scsi.h>. It gets populated with scsi
  host, channel, device id and lun data for the given device.
  Unfortunately that header file "hides" that structure
  behind a "#ifdef __KERNEL__" block. To use this, that
  structure needs to be replicated in the user's program.
  Something like:
-->
  この ioctl は 3 番目の引数として「struct scsi_idlun」オブジェクト
  へのポインタをとります。「struct scsi_idlun」の定義は、&lt;scsi/scsi.h>
  にあります。これには、そのデバイスの SCSI ホスト、チャネル、デバイス ID、
  LUN データが入っています。
  あいにく、ヘッダファイルは構造体を「#ifdef __KERNEL__」ブロックで
 「隠して」います。これを利用するには、構造体をユーザのプログラムにコピー
  しなければなりません。
  このようになります。
  typedef struct my_scsi_idlun {
      <!--
      int four_in_one;    /* 4 separate bytes of info
                            compacted into 1 int */
      int host_unique_id; /* distinguishes adapter cards from
                             same supplier */
      -->
      int four_in_one;    /* 4 つの独立したバイトを 
                             1 つの int にまとめてある */
      int host_unique_id; /* 同じメーカー製カードと区別 */
  } My_scsi_idlun;
  <!--
      "four_in_one" is made up as follows:
      (scsi_device_id | (lun &lt;&lt; 8) | (channel &lt;&lt; 16) |
      (host &lt;&lt; 24))
  These 4 components are assumed (or masked) to be 1 byte each.
  -->
     「four_in_one」は、下記のように構成されています。
      (scsi_device_id | (lun &lt;&lt; 8) | (channel &lt;&lt; 16) |
      (host &lt;&lt; 24))
  これら 4 つの部分はそれぞれ 1 バイトである(でマスクしてある)ことが
  前提になっています。
SCSI_IOCTL_GET_BUS_NUMBER
  <!--
  In lk 2.2 and earlier this ioctl was needed to get the
  host number. During lk 2.3 development the
  SCSI_IOCTL_GET_IDLUN ioctl was changed to include this
  information. Hence this ioctl is only needed for
  backward compatibility.
  -->
  Linux カーネル 2.2 以前では、この ioctl にはホスト番号が必要でした。
  Linux カーネル 2.3 開発版になって、SCSI_IOCTL_GET_IDLUN ioctl が変更に
  なり、この情報が入るようになりました。したがって、この ioctl は下位互換性
  のためにだけ必要です。
SCSI_IOCTL_TAGGED_ENABLE
  <!--
  Probably a remnant of the past when the mid level
  addressed such issues. Now this functionality is
  controlled by the lower level drivers. Best ignored.
  -->
  おそらく、中間レベルが以前扱っていた時の名残りです。現状この機能は、
  低レベルのドライバが制御しています。無視するのが一番です。
SCSI_IOCTL_TAGGED_DISABLE
  <!--
  See comment for SCSI_IOCTL_TAGGED_ENABLE.
  -->
  SCSI_IOCTL_TAGGED_ENABLE のコメントを見てください。
SCSI_IOCTL_PROBE_HOST
  <!--
  This ioctl expects its 3rd argument to be a pointer to
  a union that looks like this:
  -->
  この ioctl は 3 番目の引数に下記のような共用体へのポインタを要求します。
  union probe_host {
    <!--
    unsigned int length;  /* [i] max length of
                                 output ASCII string */
    char str[length];     /* [o] N.B. may need '\0' 
    				 appended */
    -->
    unsigned int length;  /* [i] ASCII 文字列出力の最大長 */
    char str[length];     /* [o] 注意。'\0' を加える必要があるかも
                                 しれない */
  };
  <!--
  The host associated with the device's fd either has a
  host dependent information string or failing that its
  name, output into the given structure. Note that the
  output starts at the beginning of given structure
  (overwriting the input length). N.B. A trailing '\0'
  may need to be put on the output string if it has been
  truncated by the input length. A return value of 1
  indicates the host is present, 0 indicates that the
  host isn't present (how can that happen?) and a
  negative value indicates an error.
  -->
  デバイスの fd に対応したホストは、ホストに依存した情報の文字列か、
  それがなければホストの名前が与えられた構造体に出力されます。出力は与えられた
  構造体の先頭から出力が行われることに注意してください(入力の length は上書き
  される)。「注意」出力文字列が length に切り詰められた場合は、末尾に「\0」を
  加える必要があるかもしれません。返り値が 1 の場合はホストが存在することを
  表し、0 の場合はホストが存在しないことを表します(どのような場合？)。負の値
  はエラーを意味します。

SCSI_IOCTL_DOORLOCK
SCSI_IOCTL_DOORUNLOCK
SCSI_IOCTL_TEST_UNIT_READY
<!--
  Returns 0 if the unit (device) is ready, a positive
  number if it is not or a negative number when there
  is an OS error.
-->
  ユニット(デバイス)が準備できていれば 0 が返り、準備ができていなければ
  正の値が返り、OS のエラーが発生した場合は負の値が返ります。

SCSI_IOCTL_START_UNIT
SCSI_IOCTL_STOP_UNIT
<!--
SCSI_EMULATED_HOST          {same as SG_EMULATED_HOST &lt;new>}
-->
SCSI_EMULATED_HOST          {SG_EMULATED_HOST &lt;new>と同じ}

SCSI_IOCTL_GET_PCI
<!--
  Yields the PCI slot name (pci_dev::slot_name) associated with the lower
  level (adapter) driver that controls the current device. Up to 8 characters
  are output to the locations pointed to by 'arg'. If the current device
  is not controlled by a PCI device then errno is set to ENXIO.
  [This ioctl() was introduced in lk 2.4.4]
-->
  低レベル(アダプタ)に対応したPCI のスロット名(pci_dev::slot_name)のうち、
  現在デバイスを制御しているものを表示します。最大 8 文字が「引数」で指定
  された場所に出力されます。現在のデバイスが PCI デバイスによって制御されて
  いなければ、errno に ENXIO が設定されます。(この ioctl()は、Linux カーネル 
  2.4.4 で導入されました)。
</programlisting>
</para>
</sect2>
</sect1>

<sect1 id="cosd">
      <!--
  		<title>sd driver</title>
  		-->
  		<title>sd ドライバ</title>
<para>
</para>

<sect2 id="cosdco">
  		<!--
      <title>sd compile options</title>
  		-->
      <title>sd のコンパイルオプション</title>
<para>
<programlisting>
MAX_RETRIES     {5}
SD_TIMEOUT      {30 seconds}
SD_MOD_TIMEOUT  {75 seconds}
</programlisting>
</para>
</sect2>

<sect2 id="cosdio">
  		<!--
      <title>sd ioctls and user interface</title>
  		-->
      <title>sd の ioctl と ユーザインタフェース</title>
<para>
<!--
The relevant files to see:
-->
関連するファイルは下記の通りです。
<programlisting>
include/linux/hdreg.h
include/linux/genhd.h
include/linux/fs.h
</programlisting>
</para>
<para>
<!--
A list of ioctl()s follow:
-->
ioctl()のリストは下記の通りです。
<programlisting>
HDIO_GETGEO_BIG
<!--
HDIO_GETGEO     [retrieve disk geometry]
BLKGETSIZE      [number of sectors in device]
BLKROSET        [set read only flag]
BLKROGET        [get read only flag]
BLKRASET        [set read ahead value]
BLKRAGET        [get read ahead value]
BLKFLSBUF       [instructs SCSI subsystem to flush buffers]
BLKSSZGET       [get device block size]
BLKPG		[partition table manipulation]
BLKELVGET       [get elevator parameters]
BLKELVSET       [set elevator parameters]
BLKRRPART       [reread the partition table]

open()    (all flags ignored)
close()
ioctl()   (see list above)
-->
HDIO_GETGEO     [ディスクのジオメトリを取得]
BLKGETSIZE      [デバイスのセクタ数]
BLKROSET        [リードオンリーフラグの設定]
BLKROGET        [リードオンリーフラグの取得]
BLKRASET        [先読み値の設定]
BLKRAGET        [先読み値の取得]
BLKFLSBUF       [SCSI サブシステムにバッファをフラッシュするように命令]
BLKSSZGET       [デバイスのブロックサイズを取得]
BLKPG		[パーティションテーブルの操作]
BLKELVGET       [elevator パラメタの取得]
BLKELVSET       [elevator パラメタの設定]
BLKRRPART       [パーティションテーブルの再読み込み]

open()    (フラグすべて無視)
close()
ioctl()   (上記のリストを参照)
</programlisting>
</para>
</sect2>
</sect1>

<sect1 id="cosr">
  		<!--
      <title>sr driver</title>
  		-->
      <title>sr ドライバ</title>
<para>
</para>

<sect2 id="cosrco">
  		<!--
      <title>sr compile options</title>
  		-->
      <title>sr のコンパイルオプション</title>
<para>
<!--
None.
-->
ありません。
</para>
</sect2>

<sect2 id="cosrio">
  		<!--
      <title>sr ioctls and user interface</title>
  		-->
      <title>sr の ioctl と ユーザインタフェース</title>
<para>
<!--
See the following files:
-->
下記のファイルを見てください。
<programlisting>
/usr/src/linux/include/linux/cdrom.h
/usr/src/linux/drivers/cdrom/cdrom.c [revision history section]
/usr/src/linux/Documentation/cdrom/cdrom-standard.tex
</programlisting>
</para>
<para>
<!--
Some of the following ioctls are described in cdrom-standard.tex :
-->
下記の ioctl のいくつかは、cdrom-standard.tex で記述されています。
<programlisting>
CDROMCLOSETRAY
CDROM_SET_OPTIONS
CDROM_CLEAR_OPTIONS
CDROM_SELECT_SPEED
CDROM_SELECT_DISC
CDROM_MEDIA_CHANGED
CDROM_DRIVE_STATUS
CDROM_CHANGER_NSLOTS
CDROM_LOCKDOOR
CDROM_DEBUG
CDROM_GET_CAPABILITY
DVD_READ_STRUCT
DVD_WRITE_STRUCT
DVD_AUTH
CDROM_SEND_PACKET
CDROM_NEXT_WRITABLE
CDROM_LAST_WRITTEN
</programlisting>
</para>
<para>
<!--
The O_NONBLOCK flag on the open() of scd devices is important. Without it the
open() will wait until there is media in the device before returning.
-->
scd デバイスの open()に使われる O_NONBLOCK フラグは重要です。これがないと、
媒体がデバイスに入いるまで、open()がリターンをずっと待つことになります。
<programlisting>

open()          O_NONBLOCK
close()
read()
write()
ioctl()
</programlisting>
</para>
</sect2>
</sect1>

<sect1 id="cost">
  		<!--
      <title>st driver</title>
  		-->
      <title>st ドライバ</title>
<para>
</para>

<sect2 id="costco">
  		<!--
      <title>st compile options</title>
  		-->
      <title>st のコンパイルオプション</title>
<para>
<!--
Most of the following compile options can be overridden with
boot/module parameters and/or runtime configuration (i.e. ioctls).
-->
下記のコンパイルオプションの大部分は、ブート時もしくはモジュールロード時
のパラメタと実行時の設定(例えば ioctl)の両方もしくはどちらか一方で上書き
可能です。
</para>
<para>
<!--
The following parameters are defined in linux/drivers/scsi/st_options.h
-->
下記のパラメタは、linux/drivers/scsi/st_options.h で定義されています。
<programlisting>
ST_NOWAIT                    {0}
ST_IN_FILE_POS               {0}
ST_RECOVERED_WRITE_FATAL     {0}
ST_DEFAULT_BLOCK             {0}
ST_BUFFER_BLOCKS             {32}
ST_WRITE_THRESHOLD_BLOCKS    {30}
ST_MAX_BUFFERS               {4}
ST_MAX_SG                    {16}
ST_FIRST_SG                  {8}
ST_FIRST_ORDER               {5}
ST_TWO_FM                    {0}
ST_BUFFER_WRITES             {1}
ST_ASYNC_WRITES              {1}
ST_READ_AHEAD                {1}
ST_AUTO_LOCK                 {0}
ST_FAST_MTEOM                {0}
ST_SCSI2LOGICAL              {0}
ST_SYSV                      {0}
</programlisting>
</para>
<para>
<!--
The following parameters are defined in linux/drivers/scsi/st.c
-->
下記のパラメタは、linux/drivers/scsi/st.c に定義されています。
<programlisting>
ST_TIMEOUT                   {900*HZ}
ST_LONG_TIMEOUT              {14000*HZ}
</programlisting>
</para>
</sect2>

<sect2 id="costio">
  		<!--
      <title>st ioctls and user interface</title>
  		-->
      <title>st の ioctl と ユーザインタフェース</title>
<para>
<!--
The Linux tape interface is defined in
-->
Linux のテープインタフェースは、
<filename>/usr/src/linux/include/linux/mtio.h </filename>.
で定義されています。
</para>
<para>
<!--
The following ioctl()s are listed in alphabetical order with a brief
explanation to the right. [See st documentation (especially
<command>man 4 st</command>) for more details.]
-->
下記の ioctl()はアルファベット順にリストしてあり、簡単な説明が右側にあります。
(st のドキュメント(特に <command>man 4 st</command>) を参照。)
<programlisting>
<!--
MTIOCTOP   [execute tape commands and set drive/driver options]
MTIOCGET   [get the status of the drive]
MTIOCPOS   [get the current tape location]
-->
MTIOCTOP   [テープコマンドを実行し、ドライブやドライバのオプションを設定]
MTIOCGET   [ドライバの状態を取得]
MTIOCPOS   [現在のテープ位置を取得]

open()   O_RDONLY, O_RDWR
close()
read()
write()
ioctl()
</programlisting>
</para>
</sect2>
</sect1>

<sect1 id="cosg">
  		<!--
      <title>sg driver</title>
  		-->
      <title>sg ドライバ</title>
<para>
<!--
The following header files in the kernel source are relevant to the sg driver:
-->
カーネルソースにある下記のヘッダファイルが、sg ドライバに関連しています。
<programlisting>
        /usr/src/linux/include/scsi/sg.h
</programlisting>
</para>
<para>
<!--
As pointed out in <xref linkend="coml"/> this is best included in
applications by using:
-->
<xref linkend="coml"/>で指摘した通り、アプリケーションからの利用にあたっては、
<programlisting>
    #include &lt;linux/../scsi/sg.h>
</programlisting>
のようにインクルードするのが最善です。
</para>

<sect2 id="cosgco">
  		<!--
      <title>sg compile options</title>
  		-->
      <title>sg のコンパイルオプション</title>
<para>
<!--
Here are some defines from the sg.h file that the user could conceivably want
to change. The current default values are shown in braces on the right:
-->
ここでは sg.h に定義してある内、ユーザが変更したいと思われるものをいくつか
挙げてあります。現状のデフォルトの値は、右側の{}内に表示してあります。
<programlisting>

SG_SCATTER_SZ           {32768}
SG_DEF_RESERVED_SIZE    {SG_SCATTER_SZ}
SG_DEF_FORCE_LOW_DMA    {0}
SG_DEF_FORCE_PACK_ID    {0}
SG_DEF_KEP_ORPHAN       {0}
SG_MAX_QUEUE            {16}
SG_DEFAULT_RETRIES      {1}  # i.e. don't retry
SG_BIG_BUFF             {SG_DEF_RESERVED_SIZE}
SG_DEFAULT_TIMEOUT      {60 seconds}
SG_DEF_COMMAND_Q        {0 *}
SG_DEF_UNDERRUN_FLAG    {0}

<!--
* The per file descriptor copy of this flips to 1 (thus
  allowing command queuing) as soon as a write() based
  on the newer sg_io_hdr structure is detected.
-->
* 新しい sg_io_hdr 構造体に基づく write()が検出されると、ファイルごとの
   ディスクリプタにおけるコピーは、すぐ 1 に変わります(つまり、コマンド
   キューが有効になる)。
</programlisting>
</para>
</sect2>

<sect2 id="cosgio">
  		<!--
      <title>sg ioctls and user interface</title>
  		-->
      <title>sg の ioctl と ユーザインタフェース</title>
<para>
<!--
The following ioctl()s are listed in alphabetical order with a brief
explanation to the right. [See sg documentation for more details.]
-->
下記の ioctl()はアルファベット順にリストしてあり、簡単な説明が右側に
書いてあります。(sg のドキュメントを参照)。
<programlisting>

<!--
SG_EMULATED_HOST     [indicate if adapter is ide-scsi]
SG_GET_COMMAND_Q     [command queuing flag state]
SG_GET_KEEP_ORPHAN   [interrupted SG_IO keep orphan flag state]
SG_GET_LOW_DMA       ["low dma flag" (&lt;= 16 MB on i386) state]
SG_GET_NUM_WAITING   [number of responses waiting to be read()]
SG_GET_PACK_ID       [pack_id of next to read() response
                      (-1 if none)]
SG_GET_REQUEST_TABLE [yields array of requests being processed]
SG_GET_RESERVED_SIZE [current size of reserved buffer]
SG_GET_SCSI_ID       [a little more info than the mid level's
                      SCSI_IOCTL_GET_IDLUN ioctl]
SG_GET_SG_TABLESIZE  [max entries in host's scatter gather table]
SG_GET_TIMEOUT       [yields timeout (unit: jiffies
                      (10ms on i386))]
SG_GET_TRANSFORM     [state of ide-scsi's transform flag]
SG_IO                [send given SCSI command and wait for
                      response]
SG_NEXT_CMD_LEN      [change command length of next command]
SG_SCSI_RESET        [send a SCSI bus, device or host reset]
SG_SET_COMMAND_Q     [set command queuing state {old=0, new=1}]
SG_SET_DEBUG         [set debug level {0}]
SG_SET_KEEP_ORPHAN   [set SG_IO's keep orphan flag {0}]
SG_SET_FORCE_LOW_DMA [force DMA buffer low (&lt;= 16 MB on i386)
                      {0}]
SG_SET_FORCE_PACK_ID [so read() can fetch by pack_id {0}]
SG_SET_RESERVED_SIZE [change default buffer size
                      {SG_DEF_RESERVED_SIZE}]
SG_SET_TIMEOUT       [change current timeout {60 secs} ]
SG_SET_TRANSFORM     [set ide-scsi's ATAPI transform flag {0}]

open()    [recognized oflags: O_RDONLY, O_RDWR, O_EXCL,
           O_NONBLOCK]
close()
read()
write()
ioctl()
poll()    [used when in O_NONBLOCK mode]
fasync()  [enables generation of SIGIO signal for read()]
-->
SG_EMULATED_HOST     [アダプタが ide-scsi かどうかを示す]
SG_GET_COMMAND_Q     [コマンドキューフラグの状態]
SG_GET_KEEP_ORPHAN   [中断された SG_IO keep orphan フラグの状態]
SG_GET_LOW_DMA       [「low dma フラグ」(i386 で &lt;= 16 MB)の状態]
SG_GET_NUM_WAITING   [read()待ち応答数]
SG_GET_PACK_ID       [次に read()する pack_id 応答(無い場合は -1)]
SG_GET_REQUEST_TABLE [実行されたリクエストの配列を生成]
SG_GET_RESERVED_SIZE [予約バッファの現状の大きさ]
SG_GET_SCSI_ID       [中間レベルの SCSI_IOCTL_GET_IDLUN ioctl よりも少し
                      詳しい情報]
SG_GET_SG_TABLESIZE  [ホストの scatter gather テーブルの最大エントリー数]
SG_GET_TIMEOUT       [タイムアウトの生成(単位：ジフィー(jyffy。i386 で 10ms)]
SG_GET_TRANSFORM     [ide-scsi transform フラグの状態]
SG_IO                [SCSI コマンドを送り、応答を待つ]
SG_NEXT_CMD_LEN      [次のコマンドのコマンド長を変更]
SG_SCSI_RESET        [SCSI バス、デバイス、ホストにリセットを送る]
SG_SET_COMMAND_Q     [コマンドキューの状態を設定{old=0, new=1}]
SG_SET_DEBUG         [デバックレベルの設定{0}]
SG_SET_KEEP_ORPHAN   [SG_IO keep orphan フラグの設定 {0}]
SG_SET_FORCE_LOW_DMA [DMA buffer を low に強制(i386 で &lt;= 16 MB) {0}]
SG_SET_FORCE_PACK_ID [pack_id で read()を実行{0}]
SG_SET_RESERVED_SIZE [デフォルトのバッファサイズを変更
                      {SG_DEF_RESERVED_SIZE}]
SG_SET_TIMEOUT       [現在のタイムアウトを変更{60 secs} ]
SG_SET_TRANSFORM     [ide-scsi の ATAPI transform フラグ {0}]

open()    [認識する O_ フラグ: O_RDONLY, O_RDWR, O_EXCL, O_NONBLOCK]
close()
read()
write()
ioctl()
poll()    [O_NONBLOCK モードの時に使用]
fasync()  [read() に対する SIGIO シグナル生成を有効に]
</programlisting>
</para>
</sect2>
</sect1>
</appendix>

<appendix id="refs">
      <!--
      <title>References, Credits and Corrections</title>
      -->
      <title>参考文献と謝辞、訂正について</title>
<formalpara><title>WEB</title>
<para>
<!--
The following references are found on the web. Please alert the author
if any of these links become stale.
-->
下記の参考文献は Web で見られます。リンクが古くなっていたら、著者まで報告
してください。
</para>
</formalpara>
<para>
<anchor id="W1"/>
<!--
[W1] SCSI (draft) standards, resources:
-->
[W1] SCSI(ドラフト)規格、情報源。
<ulink url="http://www.t10.org"><literal>www.t10.org</literal></ulink>
</para>
<para>
<anchor id="W2"/>
<!--
[W2] Eric Youngdale is the chief architect of the Linux SCSI subsystem:
-->
[W2] Eric Youngdale 氏は SCSI サブシステムのチーフアーキテクトです。
<ulink url="http://www.andante.org/scsi.html">
<literal>www.andante.org/scsi.html</literal></ulink>
</para>
<para>
<anchor id="W4"/>
<!--
[W4] The author's scsi generic (sg) site is:
-->
[W4] 著者の scsi generic(sg)サイトは、
<ulink url="http://www.torque.net/sg">
<literal>www.torque.net/sg</literal></ulink>. 
<!--
The Linux Documentation Project's site includes the
-->
Linux Documentation Project のサイトに、
<ulink url="http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/">
<literal>www.tldp.org/HOWTO/SCSI-Generic-HOWTO/</literal></ulink> .
があります。
<!--
A (possibly later) version of that document can be found at
-->
ドキュメントの(最新の)バージョンは、下記にあります。
<ulink url="http://www.torque.net/sg/p/sg_v3_ho">
<literal>www.torque.net/sg/p/sg_v3_ho</literal></ulink> .
<!--
The sg_utils and sg3_utils packages, as tarballs and as binary and source 
rpms can also be found on this page. These packages and others available
for the sg driver are discussed at 
-->
sg_utils と sg3_utils パッケージも tarball とバイナリとソース、rpm で、
このページにあります。これらのパッケージやその他 sg ドライバで利用できる
ものは下記で論じます。
<ulink url="http://www.torque.net/sg/u_index.html">
<literal>www.torque.net/sg/u_index.html</literal></ulink>.
</para>
<para>
<anchor id="W5"/>
<!--
[W5] Richard Gooch's devfs site:
-->
[W5] Richard Gooch 氏の devfs サイトは、
<ulink url="http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html">
<literal>www.atnf.csiro.au/~rgooch/linux/docs/devfs.html</literal></ulink>
</para>
<para>
<anchor id="W6"/>
<!--
[W6] Kurt Garloff's site (including the <command>scsidev</command> 
and the <command>scsiinfo</command> utilities):
<ulink url="http://www.garloff.de/kurt/linux/">
<literal>www.garloff.de/kurt/linux/</literal></ulink>. Kurt also has
the damaged media rescue program <command>dd_rescue</command> at this site: 
-->
[W6] Kurt Garloff 氏のサイト(<command>scsidev</command> と 
<command>scsiinfo</command> ユーティリティを含む)は、
<ulink url="http://www.garloff.de/kurt/linux/">
<literal>www.garloff.de/kurt/linux/</literal></ulink>. Kurt 氏は壊れた媒体
を復旧するプログラム <command>dd_rescue</command> をこのサイトで用意して
います。
<ulink url="http://www.garloff.de/kurt/linux/ddrescue">
<literal>www.garloff.de/kurt/linux/ddrescue</literal></ulink>
</para>
<para>
<anchor id="W7"/>
<!--
[W7] Drew Eckhardt's SCSI-HOWTO from 1996 (in ASCII):
-->
[W7] Drew Eckhardt 氏の 1996 年の SCSI-HOWTO(ASCII形式)は、
<ulink url=
"http://metalab.unc.edu/pub/Linux/docs/HOWTO/unmaintained/SCSI-HOWTO">
<literal>metalab.unc.edu/pub/Linux/docs/HOWTO/unmaintained/SCSI-HOWTO
</literal></ulink>
</para>
<para>
<anchor id="W8"/>
[W8] Linux Documentation Project (LDP):
<ulink url="http://tldp.org">
<literal>tldp.org</literal></ulink>
</para>
<para>
<anchor id="W9"/>
<!--
[W9] SCSI Trade Association site has a lot of useful information:
-->
[W9] SCSI Trade Association サイトには、たくさんの役立つ情報があります。
<ulink url="http://www.scsita.org">
<literal>www.scsita.org</literal></ulink>
</para>
<para>
<anchor id="W10"/>
<!--
[W10] SCSI FAQ site - useful source of information and links:
-->
[W10] SCSI FAQ サイト− 役立つ情報源とリンク集。
<ulink url="http://www.scsifaq.org">
<literal>www.scsifaq.org</literal></ulink>
</para>

<!--
<formalpara><title>NEWSGROUPS</title>
-->
<formalpara><title>ニュースグループ</title>
<para>
<!--
The following entries are actually reflectors rather than newsgroups.
Various web locations archive their contents (e.g.
-->
下記のエントリーはニュースグループではなく、ニュースグループのリフレクタ
(内容を ML へ流しているもの)です。
これらは web のいろいろな場所 (例えば
<ulink url="http://marc.theaimsgroup.com"><literal>marc.theaimsgroup.com</literal></ulink>)でアーカイブされています。
</para>
</formalpara>
<para>
<anchor id="N1"/>
[N1] Linux SCSI reflector: <email> linux-scsi@vger.kernel.org </email>.
<!--
This is a relatively low volume (circa 200 postings per month) Linux
SCSI specific group that many of the SCSI subsystem maintainers
monitor.
-->
比較的投稿量が少ない(月当たり約 200 通)Linux SCSI 専用のグループで、SCSI 
サブシステムのメンテナーの多くが見ています。
</para>
<para>
<anchor id="N2"/>
[N2] Linux kernel reflector: <email> linux-kernel@vger.kernel.org </email>.
<!--
This is a relatively high volume (circa 5000 postings per month) group
for all aspects of the Linux kernel. The Linux SCSI reflector should
be tried first.
-->
比較的投稿量が多い(月当たり約 5000 通)グループで、Linux カーネル全般に
ついて扱っています。まずはじめに Linux SCSI リフレクタを試してみてください。
</para>

<!--
<formalpara><title>BOOKS</title>
-->
<formalpara><title>書籍</title>
<para>
<!--
Here are some books that the author found useful.
-->
ここでは、著者が役に立つと思われる書籍をあげました。
</para>
</formalpara>
<para>
<anchor id="B1"/>
[B1] "Linux Device Drivers" Second edition by Alessandro Rubini
and Jonathan Corbet [O'Reilly 2001 ISBN 0-596-00008-1]
<!--
This is a solid text on Linux device drivers including some information
on the SCSI subsystem. It covers the block subsystem well and has
many char device driver examples. It has been updated for the Linux
2.4 series kernels and also includes information on the Linux 2.2 and 2.0
series. This book is highly recommended.
The authors
and the publisher have unselfishly made this book available under the GNU
Free Documentation License (version 1.1). It can be found in html at
<ulink url="http://www.oreilly.com/catalog/linuxdrive2/chapter/book">
<literal>www.oreilly.com/catalog/linuxdrive2/chapter/book</literal></ulink> .
-->
この書籍は、SCSI サブシステムの情報を含む、Linux デバイス・ドライバについて
信頼が置けます。ブロックサブシステムと同様、キャラクタデバイスについても、
たくさんの例が載っています。Linux 2.4 系のカーネルに追随しており、
Linux 2.2 と 2.0 の情報も載っています。この書籍を強くお勧めできます。
著者と出版社は寛大で、この書籍を GNU フリー文書利用許諾契約書
(バージョン 1.1)として利用できるようにしました。html 形式で、
<ulink url="http://www.oreilly.com/catalog/linuxdrive2/chapter/book">
<literal>www.oreilly.com/catalog/linuxdrive2/chapter/book</literal></ulink>
に置いてあります。
</para>

<para>
【訳註：「Linux Device Drivers」の日本語訳が出版されています。
<ulink url="http://www.oreilly.co.jp/BOOK/lidriver2/">
「Linux デバイスドライバ 第 2 版」</ulink>】
</para>

<para>
<anchor id="B2"/>
[B2] "Running Linux" 3rd edition by M. Welsh, M. K. Dalheimer &amp; L. Kaufman
        [O'Reilly 1999 ISBN 1-56592-469-X]
<!--
This is a classic Linux tome which includes some SCSI configuration info.
-->
これは SCSI の設定情報を含む Linux 大全の傑作です。
</para>
<para>
【訳註：「Running Linux」の翻訳本が出版されています。
<ulink url="http://www.oreilly.co.jp/BOOK/rulinux4/">
「Running Linux 第 4 版」</ulink>】
</para>
<para>
<anchor id="B3"/>
[B3] "The Programmer's Guide to SCSI" by Brian Sawert [Addison Wesley 1998
        ISBN 0-201-18538-5]
<!--
This book covers many SCSI topics, including the pass through mechanisms
of Linux (sg) and ASPI/ASPI32 as used by Windows.
-->
これは、SCSI のトピックをたくさん載せていて、Linux(sg)のしくみや Windows 
で使われている ASPI や ASPI32 も一通り扱っています。
</para>
<!--
<formalpara><title>CREDITS</title>
-->
<formalpara><title>謝辞</title>
<para>
<!--
The author is grateful for the following contributions:
-->
貢献していただいた、下記の方々に感謝致します。
<itemizedlist>
<listitem><para>Kai M&auml;kisara (st)  <email>Kai.Makisara@metla.fi</email>
</para></listitem>
<listitem><para>Jens Axboe (sr)  <email>axboe@suse.de</email>
</para></listitem>
<listitem><para>Richard Gooch (devfs)  <email>rgooch@atnf.csiro.au</email>
</para></listitem>
<listitem><para>Tim Waugh (ppa, imm, ppscsi + docbook)
<email>twaugh@redhat.com</email>
</para></listitem>
<listitem><para>Gadi Oxman (ide-scsi)
<email>gadio@netvision.net.il</email>
</para></listitem>
</itemizedlist>
</para>
</formalpara>

<formalpara><title>日本語版謝辞</title>
<para>
この翻訳を行うに当たって、下記の方にお世話になりました。
この場をかりてお礼申し上げます。
<itemizedlist>
<listitem><para>中野武雄さん</para></listitem>
<listitem><para>ちくわふさん</para></listitem>
</itemizedlist>
</para>
</formalpara>

<!--
<formalpara><title>CORRECTIONS and SUGGESTIONS</title>
-->
<formalpara><title>訂正と提案</title>
<para>
<!--
Please send any corrections or suggestions to the author at
-->
訂正や提案があればどのようなものでも、著者までお送りください。
<email>dgilbert@interlog.com</email> or <email>dougg@torque.net</email> .
</para>
</formalpara>

</appendix>
</book>
