docs/writing_udev_rules/index.jp.html

   1 <html><head><title>udevルールの書き方</title>
   2
   3 <meta name="resource-type" content="document"></head>
   4 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   5 <body>
   6
   7 <h1>udevルールの書き方</h1>
   8 Daniel Drake (dsd) 著<br />
   9 バージョン 0.6<br /><br />
  10
  11 この文書の最新バージョンは、常に以下のサイトにあります。<br />
  12 <a href="http://www.reactivated.net/udevrules.php">http://www.reactivated.net/udevrules.php</a>(英語オリジナルサイト)<br />
  13 <a href="http://www.gentoo.gr.jp/transdocs/udevrules/udevrules.html">http://www.gentoo.gr.jp/transdocs/udevrules/udevrules.html</a>(日本語翻訳版)<br /><br />
  14
  15 日本語翻訳版は、著者に許可を得て、五十嵐 正尚(igarashi@gentoo.gr.jp)が翻訳し、GentooJPで公開しているものです。翻訳版に関することは訳者に連絡してください。<br />
  16 日本語翻訳版 最終更新日 2005-05-16
  17
  18 <h2>内容</h2>
  19 <ol>
  20 <li><a href="#about">この文書について</a></li>
  21 <li><a href="#history">更新履歴</a></li>
  22 <li><a href="#versions">執筆時に使用したソフトウェアのバージョン</a></li>
  23 <li><a href="#terminology">用語紹介: devfs、sysfs、ノードなど</a></li>
  24
  25 <li><a href="#why">なぜルールを書く必要がありますか? (この文書の目的)</a></li>
  26 <li><a href="#basics">ルールを書く上での基本事項</a></li>
  27 <li><a href="#operators">NAMEとSYMLINKパラメータでの設定自動化のための付加機能</a></li>
  28 <li><a href="#regexp">キーでのシェル形式パターン照合の使い方</a></li>
  29 <li><a href="#keys">キーを書く上での基本事項</a></li>
  30 <li><a href="#identify-keys">基本キーによるデバイス識別方法</a></li>
  31 <li><a href="#identify-sysfs">SYSFSファイルによるデバイス識別方法</a></li>
  32 <li><a href="#multiple-symlinks">複数SYMLINK形式の使い方</a></li>
  33 <li><a href="#mode-owner-group">所有権とパーミッション制御</a></li>
  34 <li><a href="#example-printer">例: 著者所有のUSBプリンタ向けのルールの書き方</a></li>
  35 <li><a href="#example-camera">例: USBストレージ方式対応デジカメ向けのルールの書き方</a></li>
  36
  37 <li><a href="#usbstorage-extra">USBストレージ向けルールの書き方に関する追記</a></li>
  38 <li><a href="#example-cdrom">例: 著者所有のCDドライブに便利なルールの書き方</a></li>
  39 <li><a href="#example-iface">例: 著者所有のネットワークインターフェースに名前を付けるルールの書き方</a></li>
  40 <li><a href="#tips">SYSFS内におけるudevinfoを実行すべき場所を探し出すコツ</a></li>
  41 <li><a href="#debugging">ルールのデバッグ方法</a></li>
  42 <li><a href="#author">著者と謝辞</a></li>
  43 </ol>
  44
  45 <a name="about"></a>
  46 <h2>この文書について</h2>
  47 udevはLinuxカーネル2.6以降を対象とし、デバイス名を固定する機能を備え、動的な/devディレクトリをユーザスペースで実現する方法を提供します。
  48 これまでの/devの実装である<i>devfs</i>は、現在後方互換のためだけに残されており、udevはその後任と考えられています。
  49 udevとdevfsではどちらが良いかということは、慎重に議論されるべき問題です。
  50 ご自分で比較する前に、まず<a href="http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs">この文書</a>を読むべきです。<br /><br />
  51 udevはよく考え抜かれていますが、私は最初、自分のシステムではどのように調整すればよいのかとても戸惑いました。この文書では、ルールを書く手順がもう少し明確になることを目指しています。<br /><br />
  52
  53 いつでも意見や感想をお待ちしております。どんな意見、問題、改善案でも<a href="#author">連絡先</a>にお願いします。<br /><br />
  54 この文書は、udev/hotplugをインストール済みであり、初期設定で問題なく動作していることを想定しています。まだudevを設定しておらず、動作していないなら、<a href="http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html#UDEV">Decibels udev Primer</a><a href="http://www.gentoo.gr.jp/transdocs/decibelshelp/LinuxHelp_UDEVPrimer.html#UDEV">(日本語訳)</a>に従ってその作業を行うことをお勧めします(少しGentoo Linux固有のことが含まれていますが、他のディストリビューションにも有用なはずです)。<br /><br />
  55
  56 <a name="history"></a>
  57
  58 <h2>更新履歴</h2>
  59
  60 2005年5月9日 v0.6: udevinfo、グループとパーミッション、ログ取り、udevtestに関する情報を含む様々な更新。<br /><br />
  61 2004年6月20日 v0.55: 複数シンボリックリンク形式に関する情報を追加。細かい変更/更新。<br /><br />
  62 2004年4月26日 v0.54: Debian情報を追加。細かい修正。
  63 ルールファイルをなんと呼ぶべきかに関しての情報を過去ものに戻した。
  64 ネットワークインターフェースの名前付けに関する情報を追加。<br /><br />
  65 2004年4月15日 v0.53: 細かい修正。NAME{all_partitions}に関する情報を追加。udevinfoを使用する際のコツに関する別の情報を追加。<br /><br />
  66 2004年4月14日 v0.52: udevの初期設定が他のファイルを考慮するようになるまで、udev.rulesの使用を推奨するように戻した。細かい作業。<br /><br />
  67 2004年4月6日 v0.51: udev.rulesの先頭に追加するより、各自のlocal.rulesファイルの使用を推奨するように書いた。<br /><br />
  68 2004年4月3日 v0.5: ちょっとした整理とudev配布物に含まれる可能性があるため、その準備。<br /><br />
  69 2004年3月20日 v0.4: 全体的に改良、明確化、および整理。USBストレージ向けのルールの書き方に関する情報をさらに追加。<br /><br />
  70 2004年2月23日 v0.3: sysfsの名前付け動作方法とそれにどのように一致させるかを強調するために、いろんな部分を書き直し。
  71 udev 018の新しいSYSFS{filename}名前付け規則を説明するルールの書き方を更新。
  72 セクションの体裁を改良と、いろんな箇所をわかりやすくした。KDEに関する情報を追加。<br /><br />
  73 2004年2月18日 v0.2: 例の中のちょっとした間違いを修正。
  74 マスストレージデバイスの識別に関するセクションを更新。nvidiaのセクションを更新<br /><br />
  75 2004年2月15日 v0.1: 最初の公開。<br /><br />
  76
  77 <a name="versions"></a>
  78 <h2>執筆時に使用したソフトウェアのバージョン</h2>
  79 Linuxカーネル 2.6.11<br />
  80 udev 056<br /><br />
  81
  82 <a name="terminology"></a>
  83 <h2>用語紹介: devfs、sysfs、ノードなど</h2>
  84 <font size="2">基本的な紹介だけです。完全に正確ではないかもしれません。</font><br /><br />
  85
  86 標準的なlinuxを基本とするシステムでは、<i>/dev</i>ディレクトリは、ファイルに似たデバイス<b>ノード</b>を保持するために使用されます。
  87 デバイスノードは、システムに含まれる特定のデバイスに対応します。
  88 各ノードは、システム構成の一部(デバイス)を指します。デバイスは、実際に存在するかもしれないし、存在しないかもしれません。
  89 ユーザスペースで動作するアプリケーションは、システムハードウェアとやり取りをするためにこれらのデバイスノードを使用できます。例えば、ユーザが行うマウス動作を、画面上のマウスポインタの動きに結びつけるために、XFree86は/dev/input/miceを監視します。<br /><br />
  90
  91 もともとの<i>/dev</i>ディレクトリは、システムに組み込まれる可能性のある全てのデバイスが配置されていました。
  92 そんなわけで/devディレクトリは、一般的にとても大きくなっていました。
  93 <b>devfs</b>は、もろもろの機能に加え、より扱いやすい手法(特に目を引くのは、システムに接続されたハードウェアだけが/devに配置されたことでした)を提供するために登場しました。
  94 しかし、devfsには簡単に解決することができない問題があることが判明しました。<br /><br />
  95
  96 <b>udev</b>は、<i>/dev</i>ディレクトリを管理する新しい手法です。
  97 過去の<i>/dev</i>実装にある問題を解決するように設計され、将来にわたって破綻しないものを提供します。
  98 udevは、ユーザが指定する<i>ルール</i>と<i>sysfs</i>によって提供される情報を照合して、システムに組み込まれたデバイスに相当する<i>/dev</i>デバイスノードを作成し命名します。
  99 ルールを書く工程は、ユーザが(選択的に)行う必要がある数少ないudevに関係する作業のうちの一つです。
 100 この文書は、そのルールを書く工程を詳しく説明することが目的です。<br /><br />
 101
 102 <b>sysfs</b>は、2.6カーネル向けの新しいファイルシステムです。
 103 sysfsはカーネルによって管理され、システムに接続されているデバイスに関する基本情報をユーザスペースに提供します。
 104 udevは、ハードウェアに相当するデバイスノードを作成するために、この情報を使用します。
 105 sysfsは<i>/sys</i>にマウントされることで、情報を読み出せる状態になります。
 106 udevに取り組む前に、まず/sysにあるファイル群を調査したいとお思いになるでしょう。この文書全体に渡って、用語<i>/sys</i>と<i>SYSFS</i>を使用します。どちらにも読み替え可能です。<br /><br /><br />
 107
 108 <a name="why"></a>
 109 <h2>なぜルールを書く必要がありますか?</h2>
 110 上で述べたように、udevのルールを書くかどうかは、自由に選択できます。
 111 初期設定でも、デバイスを接続することができ、過去の<i>/dev</i>実装でのように、そのデバイスに適切なノード(例えば、マスストレージデバイス用である<i>/dev/sda</i>など)が作成されるでしょう。<br /><br />
 112 しかし、udevはデバイスノードの名前を自由に変えることができます。
 113 名前を変更したくなる理由には、利便性とデバイス名の固定化の二つが考えられます。<br /><br />
 114
 115 プリンタが接続されたときに、<i>/dev/printer</i>として命名され、さらにいつもの<i>/dev/lp0</i>も存在するようにする場合のudevの使用例を挙げます。
 116 この例は、利便性(例えば、lp0ではなくprinterに読み替える)だけではなく、変更になる可能性のある名前への対策であることを意図しています。
 117 私は二つのプリンタ(HPのレーザプリンタと、EPSONのインクジェット)を持っています。
 118 それらプリンタの両方が接続され、システムに組み込まれるた場合、/dev/lp0と/dev/lp1になります。<br />
 119 どうすれば、どちらのノードがどちらのプリンタを指しているかを知ることができるでしょう。
 120 簡単な方法はありません。接続された順で、最初のプリンタがlp0を割り当てられ、二番目がlp1に割り当てられます。異なる順番でプリンタが接続されると、この名前は逆になります。そして、それは常にHPのレーザプリンタがlp1であることを想定している私のスクリプトを混乱させるでしょう。<br /><br />
 121 しかし、もしHPレーザプリンタに(lpXに加えて)lp_hpの名前が与えられ、一方のプリンタに(lpYに加えて)lp_epsonの名前が与えられるなら、私のスクリプトは、これらの名前を使えるでしょう。udevの魔法は、このようなことを制御でき、このような<b>固定された名前</b>が常に意図するデバイスを指すことを確実にします。<br /><br />
 122 この名前の固定化機能は、外部マスストレージデバイス(例えば、USBハードディスク)において、<i>/etc/fstab</i>に正確なデバイスを書き込むことを可能にするのに、とても役に立ちます。<br /><br />
 123
 124 ルールを書くことは、udevの動作を調整する一つの手段でしかないという認識を持つことが大切です。
 125 ルールを書くことは、既存の特定デバイスに対応するデバイスノードがない場合の問題に対する<b>回避策ではありません</b>。
 126 該当する既存のルールがない場合、udevはカーネルが提供する名前を使ってとにかくノードを作成します。<br /><br />
 127
 128 <a name="basics"></a>
 129 <h2>ルールを書く上での基本事項</h2>
 130
 131 udevは、<i>/dev</i>の下を配置するときに、一連のルールファイルを読んで、どのノードを含めるかと、それらのノードにどのような名前を付けるかを決定します。<br /><br />
 132
 133 初期設定のudevルールは、<i>/etc/udev/rules.d/50-udev.rules</i>にあります。
 134 このファイルにざっと目を通すとおもしろいことが分かるかもしれません。
 135 そこには少しの例や、いくつかのdevfs形式の/devレイアウトを提供する初期設定ルールが含まれています。
 136 しかし、今後udevを更新するときに起こりうる面倒を軽減するために、このファイルにルールを直接書くべきではありません。<br /><br />
 137
 138 <i>/etc/udev/rules.d/</i>にあるファイルは、<b>辞書順</b>で解析されます。
 139 udevは、ファイル中に新しく検出されたハードウェアに一致するルールを見つけるとすぐに、ルール処理を止めます。
 140 udevの初期設定と照合される前に、ユーザが用意したルールが処理されることが重要です。そうでないと、ユーザの命名規則は無効になってしまうでしょう。
 141 <i>/etc/udev/rules.d/10-local.rules</i>ファイル(デフォルトでは存在しないので、作成してください)の中にユーザ指定のルールを保持しておくことを推奨します。
 142 10は50より前なので、ユーザ指定のルールが最初に評価されることがおわかりでしょう。
 143 ユーザ指定のルールファイルの名前は、<b>.rules</b>サフィックスで終わっている必要があります。そうしないと利用されません。<br /><br />
 144
 145 ユーザ指定のルールは、基本の/devレイアウトを作成するudevの初期設定を、事実上無効にしてしまいます。したがって、ユーザが記述するルールには、実用的である初期設定の名前とユーザ指定の名前両方を得るために、devfs形式の名前やシンボリックリンクも指定することをお勧めします。<br /><br />
 146
 147 ルールファイルでは、"#"で始まる行は、コメントとして扱われます。
 148 ルールファイルの中のコメントされてない全ての行が、ルールに相当します。<br /><br />
 149
 150 ルールは複数のキーで構成されます。複数のキーはコンマによって区切られます。
 151 一部のキーは情報の読み込みと照合用で、その他のものは、情報の割当てやアクションの実行用です。
 152 <ol>
 153 <li>システムにあるいろいろなデバイスに一致する、少なくとも一つの<i>識別キー(identification key)</i>を指定する必要があります。
 154 識別キーついては、後にある<a href="#identify-keys">基本キーによるデバイス識別方法</a>セクションに記載されています。</li>
 155 <li>結果としてデバイスノードがどのようにして作成されるかを制御するための、少なくとも一つの<i>割当てキー(assignment key)</i>を指定する必要があります。
 156 割当てキーには、NAME、SYMLINK、OWNER、GROUP、MODEがあり、このドキュメントですべて説明しています。</li>
 157 </ol>
 158
 159 一般的なルールは、デバイスに名前を付けることを決定するために、複数の基本識別キーが使われます。そして、デバイスノード名を決めるために一つの<i>NAME</i>割当てキーが指定されます。
 160 udevは、一つのデバイスに対し一つのノードだけを作成します。
 161 したがって、一つのデバイスに対し複数のノードを通してアクセスしたい場合は、<i>SYMLINK</i>割当てキーに、別のノードを指定する必要があります。<br /><br />
 162
 163 以下に例を示すためにudevの例にあるルールをちょっと修正したものを取り上げます。
 164 <blockquote><pre>BUS="usb", SYSFS{serial}="HXOLL0012202323480", NAME="lp_epson", SYMLINK="printers/epson_stylus"</pre></blockquote>
 165
 166 この場合の識別キーは、<i>BUS</i>と<i>SYSFS{serial}</i>で、割当てキーは、<i>NAME</i>と<i>SYMLINK</i>です。
 167 udevは、このルールをUSBバスによって接続され<u>かつ</u>HXOLL0012202323480のシリアルナンバーを持つデバイスに対して一致させます。
 168 <b>udevがデバイスに名前を付けるルールとして採用するには、(どれか一つではなく)<u>すべて</u>の指定されたキーが一致する必要があります。</b><br />
 169
 170 udevは、このノードを<i>lp_epson</i>と命名し、<i>/dev/lp_epson</i>に作成するでしょう。<br />
 171 udevは、さらに<i>/dev/lp_epson</i>へのシンボリックリンクを、<i>/dev/printers/epson_stylus</i>に作成します(printersディレクトリは、自動的に作成されます。)。
 172 これで、<i>/dev/printers/epson_stylus</i>もしくは<i>/dev/lp_epson</i>にデータを送ることで、EPSONプリンタで印刷することができます。<br /><br />
 173
 174 ユーザが追加または修正したどんなルールも、udevに通知するまで<b>有効にはなりません</b>。
 175 何かルールファイルを修正した場合は常に以下のコマンドを確実に実行することを忘れないでくささい。
 176 <blockquote><pre># udevstart</pre></blockquote>
 177
 178 <a name="operators"></a>
 179 <h2>NAMEとSYMLINKパラメータでの設定自動化のための付加機能</h2>
 180 ルールのNAMEとSYMLINKパラメータに、デバイスの名前づけを支援する基本オペレータを使用することができます。
 181 プログラム言語が分かる人は、この種のものを<i>printf形式に似た文字列置換</i>として知っていると思います。
 182 NAME/SYMLINKパラメータの一部もしくは全てを組み立てることが可能な、いくつかのオペレータがあります。
 183 これらオペレータは、デバイスに関するカーネルデータを参照します。
 184 以下の例を見てみましょう。
 185 <blockquote><pre>BUS="usb", SYSFS{vendor}="FUJIFILM", SYSFS{model}="M100", NAME="camera%n"</pre></blockquote>
 186
 187 <i>%n</i>オペレータは、camera0、camera1、などのようなNAMEを作成するために、カメラデバイスに対する"カーネル番号"に置き換えられます。<br /><br />
 188
 189 他にはよく使われるオペレータとして、<i>%k</i>があります。
 190 これは、例えば"hda1"などのような、カーネルがデバイスに付けると予想される名前を表します。
 191 ハードウェアのデフォルトの名前を作成するための、NAME="%k"が指定されているルールをよく見るでしょう。
 192 このようなルールでは、ユーザ指定のものは通常SYMLINKパラメータによって設定されます。<br /><br />
 193
 194 <font size="2">udevのmanページに説明付きでオペレータの全リストがあります。</font><br /><br />
 195
 196 <a name="regexp"></a>
 197 <h2>キーでのシェル形式パターン照合の使い方</h2>
 198
 199 キーを書く場合、より柔軟性を高めるためにシェル形式のパターン照合を使用することができます。以下に初期設定のudevルールを取り上げます。
 200
 201 <blockquote><pre>KERNEL="ts*", NAME="input/%k"</pre></blockquote>
 202 ここでは*オペレータが使われています。これは、文字列長が0以上のすべての種類の文字で構成される文字列全体に一致します。
 203 このルールの書き方は、以下のことを意味します。
 204
 205 <blockquote>"ts"の文字列で始まり、その後に任意で何かの文字が続くKERNEL名によって識別されるデバイスに一致し、指定ディレクトリの下にKERNEL名(%k)で名前をつけます。</blockquote>
 206
 207 ?オペレータはよく似ており、何かの一文字に一致します(0文字には一致しません)。<br /><br />
 208
 209 どれかの一文字に一致する、かぎ括弧[ ]も使用できます。以下にudevのmanページから直接引用します。<br />
 210 <blockquote>例えば, パターン文字列"tty[SR]"は、"ttyS"か"ttyR"に一致します。</blockquote>
 211 一致範囲を指定することもできます。
 212 例えば、[0-9]はいずれかの一文字の数字に一致します。
 213 以下にudevインストール直後の初期設定にあるルール例を示します。
 214 <blockquote><pre>KERNEL="fd[0-9]*", NAME="floppy/%n"</pre></blockquote>
 215
 216 このルールは以下のことを意味します。<br />
 217
 218 <blockquote>"fd"で始まり、それに一文字の何かの数字が続き、その後に任意で何かの文字が続くKERNEL名によって識別されるデバイスに一致します。フロッピーのディレクトリの下にデバイスのカーネル番号(%n)でデバイスに名前をつけます。</blockquote>
 219 これらのワイルドカード/パターン一致は、基本キーとsysfsでの識別情報の両方を含め、どのキータイプででも使用できます(キータイプに関しては後の説明を参照してください)。<br /><br />
 220
 221 <font size="2">ここでは、ルールの書き方に関する基本事項の範囲外である一部の情報(特に[ ]オペレータの柔軟性)をわざと割愛しています。
 222 これに関する詳しい情報は、udevのmanページにあります。</font><br /><br />
 223
 224 <a name="keys"></a>
 225 <h2>キーを書く上での基本事項</h2>
 226 udevは、いくつかの基本キーを照合する仕組みを提供しています。さらにSYSFS内のデバイス情報と照合するための柔軟な方法も提供します。
 227 標準的なルールは、普通のキー(BUSとKERNELなど)と、
 228 同一ポートに接続された異なるハードウェア間で区別をするSYSFSキーの両方が一致します。<br /><br />
 229 「自分のプリンタのシリアルナンバーをどうやって探せばいいの? 私のカメラのモデルは何だろう?」と疑問に思うかもしれません。
 230 ルールの書き方は、思うほど難しくありません。
 231 一番やっかいなのは/sys内で対象のデバイスを探して、どの情報を使うかを決めることです。<br /><br />
 232
 233 <a name="identify-keys"></a>
 234 <h2>基本キーによるデバイス識別方法</h2>
 235
 236 <font size="2">基本キーに関するより詳しい情報はudevのmanページを参照してください。</font><br /><br />
 237
 238 有効なキーは次のとおりです。
 239 <ul><li>BUS - デバイスのバスの種類と照合されます。</li>
 240 <li>KERNEL - カーネルデバイス名と照合されます。</li>
 241 <li>DRIVER - カーネルドライバの名前と照合されます。</li>
 242 <li>SUBSYSTEM -カーネルサブシステム名と照合されます。</li>
 243 <li>ID - バス上のデバイスナンバー(PCIバスIDなど)と照合されます。</li>
 244 <li>PLACE - デバイスが接続された物理的な位置と照合されます(USBに役に立ちます)。</li>
 245
 246 </ul>
 247 IDとPLACEキーは、役に立つこともありますが、一般的にルールでは使用されません。
 248 この文書は、BUSとKERNELキーやSYSFS{...}キー(次のセクションで説明します)の使い方に重点を置きます。
 249 例を使ってこれらのキーの使い方を示します。<br /><br />
 250
 251 <font size="2">さらに柔軟な方法として、udevは外部のスクリプトを呼び出してその結果を使うためのキーや、環境変数を使うためのキーも準備しています。
 252 これは、この文書の範囲外とします。より詳細な説明は、udevのmanページを見てください。</font>
 253
 254 <a name="identify-sysfs"></a>
 255 <h2>SYSFSファイルによるデバイス識別方法</h2>
 256
 257 <font size="2">前提となる知識: SYSFSは、ディレクトリツリーの下にハードウェアに関する情報を提供するたくさんの小さなファイルを保持しています。
 258 一つのファイルは、一般に一つだけ"データ項目"を持ちます。- 例えば、デバイス名や製造者情報やプロダクトIDがあります。<br /><br />
 259 SYSFS{...}キーは、前のセクションで説明した基本キーと組み合わせることができます。</font><br /><br />
 260
 261 特定のSYSFSの情報と照合するために、SYSFS{<i>ファイル名</i>}形式のキーを使えます。<i>ファイル名</i>は、SYSFSツリーの中のファイルに相当します。
 262 例としては、私のカメラが接続された場合、"USB 2.0M DSC"という内容で<i>/sys/block/sda/device/model</i>にファイルが存在します。これと照合するために、次のようなキーを使えます。SYSFS{model} = "USB 2.0M DSC"<br /><br />
 263
 264 <b>sysfsにある<u>すべての</u>ファイルが、この方法で照合することができます。
 265 ただ、(複数のキーを使って)一つ以上のファイルと照合させる場合、同一ディレクトリにあるファイルとだけに照合させる必要があります。</b>
 266 一般的には、一つのデバイスに関する情報を提供するディレクトリは、いくつか存在します。
 267 (後の例で示すとおり、)それらを混合して照合することはできません。<br /><br />
 268
 269 幸いにして、ルールを書く過程において、SYSFSにある無数のファイルを探し回る必要はありません。<i>udevinfo</i>ユーティリティがその大変な作業を代わりにやってくれます。このプログラムはudevの配布物の中に含まれています。<br /><br />
 270 まず始めにしなければならないことは、対象のハードウェアに対応する、"<i>dev</i>"というファイルを含むディレクトリが/sysのどこにあるかを見つけることです。
 271 udevinfoは、そのようなディレクトリ上でだけ動作可能です。
 272 これらのディレクトリは、すべてが<i>/sys/block</i>か<i>/sys/class</i>のどちらか一方の下で見つかります。
 273 - その他の場所は、どこも参照する意味がありません!
 274 しかし、udevinfoはこれらのディレクトリを経由してリンクを辿って、sysfsの別のセクションで見つかる情報を読み出します。<br /><br />
 275 一度だけこのようなディレクトリを見つければ、udevルールのキーを書く作業を手助けしてくれる以下のコマンドが使えます。
 276 <blockquote><pre># udevinfo -a -p /sys/path/to/hardware/info</pre></blockquote>
 277
 278 udevinfoを実行するための<i>/sys</i>内の適切な位置を見つけることについては、まだ明確になっていないことが分かるでしょう。
 279 接続したデバイスに対し既にデバイスノード(例えば、<i>/dev/sda</i>)が作成されている可能性があり、その場合はudevinfoが役に立ちます!
 280 私の<i>/dev/sda</i>ノードの例でいうと、以下のコマンドを実行するとsysfsの適切な位置を示してくれます。
 281 <blockquote><pre># udevinfo -q path -n /dev/sda
 282
 283 /block/sda
 284 </pre></blockquote>
 285
 286 (上記で示した)このコマンドの出力は、sysfsパスが<i>/sys/block/sda</i>で始まることを示しています。
 287 これで私は"udevinfo -a -p /sys/block/sda"を実行できます。
 288 これらの二つのコマンドは、以下のように連ねることができます。
 289
 290 <blockquote><pre># udevinfo -a -p $(udevinfo -q path -n /dev/sda)</pre></blockquote>
 291
 292 <font size="2"><i>注記: 前に示したものには、udevinfoにあらかじめフルパス(/sys/なんとか/パス)を指定していて、今回はこれらのコマンドを連結することでsysfsに関係するパスを指定していることに気が付くかもしれません。
 293 どちらでも特に問題はありません。どちらのパス形式も受け付けられます。</i></font><br /><br />
 294 ここでルールの書き方に移り、私の環境での"udevinfo -a -p /sys/block/sda"の実行結果の抜粋を、色づけをして以下に示します。<br />
 295
 296 <pre><font color="#003300">
 297 follow the class device's "device"
 298   looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3/3-3:1.0/host0/0:0:0:0':
 299     BUS="scsi"
 300     ID="0:0:0:0"
 301     SYSFS{detach_state}="0"
 302     SYSFS{type}="0"
 303     SYSFS{max_sectors}="240"
 304     SYSFS{device_blocked}="0"
 305     SYSFS{queue_depth}="1"
 306     SYSFS{scsi_level}="3"
 307     SYSFS{vendor}="        "
 308     SYSFS{model}="USB 2.0M DSC    "
 309     SYSFS{rev}="1.00"
 310     SYSFS{online}="1"</font>
 311 <font color="#0000ff">
 312   looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3':
 313     BUS="usb"
 314     ID="3-3"
 315     SYSFS{detach_state}="0"
 316     SYSFS{bNumInterfaces}=" 1"
 317     SYSFS{bConfigurationValue}="1"
 318     SYSFS{bmAttributes}="c0"
 319     SYSFS{bMaxPower}="  0mA"
 320     SYSFS{idVendor}="052b"
 321     SYSFS{idProduct}="1514"
 322     SYSFS{bcdDevice}="0100"
 323     SYSFS{bDeviceClass}="00"
 324     SYSFS{bDeviceSubClass}="00"
 325     SYSFS{bDeviceProtocol}="00"
 326     SYSFS{bNumConfigurations}="1"
 327     SYSFS{speed}="12"
 328     SYSFS{manufacturer}="Tekom Technologies, Inc"
 329     SYSFS{product}="USB 2.0M DSC"</font>
 330 </pre>
 331
 332 <i>udevinfo</i>ツールは、udevルールにそのままコピーペーストして使うことができる多くの情報を提供してくれます。
 333 上記の出力結果に色をつけた理由は、
 334 <b>通常はudevinfoの出力の異なる箇所からの情報を組み合わせて照合することができない</b>ことを示すためです。
 335 上記の出力結果で、異なる色が付いているセクションの情報を組み合わせることはできません。 - 出力結果の各セクションが、SYSFS内での異なるディレクトリを参照している情報だからです。
 336 例えば、以下のルールは機能しません。
 337 <blockquote><pre><font color="#003300">BUS="scsi"</font>, <font color="#0000ff">SYSFS{manufacturer}="Tekom Technologies, Inc"</font>, NAME="%k"</pre></blockquote>このルールは、青いセクションにだけ存在する情報とBUS="scsi"(緑)で始まるセクションにある情報と組み合わさっているので機能しません。
 338 BUS="usb"と、上記の青いセクションにある情報だけを使用しているならちゃんと機能するでしょう。<br /><br />
 339 多くの情報が、基本的なルールの書き方には関係ないことがわかるでしょう(本当にたくさんあります!)。
 340 一般的には、変更にならないことが分かっている情報(例えばモデル名)を探すべきです。<br /><br />
 341
 342 <b>デバイスを識別するユーザ指定のルールを記述すると、初期設定のdevfs形式のルールが機能しなくなることに注意してください。</b>
 343 たいていの場合、NAME="%k"を使用するのが賢明で、初期設定の実用的な名前がなくならないように、SYMLINKパラメータに追加の名前を指定してください。<br /><br />
 344
 345 以下に<i>udevinfoの出力を基にしたルールの書き方</i>の手順を三つの例で示します。
 346 その後、正確な情報を提供するために各デバイス固有の小技やコツをいくつか記述しようと思います。<br /><br />
 347
 348 <font size="2">読者の一人が、KDEのコントロールセンターがルールを書くのに役に立つということを、知らせてきました。
 349 USBデバイス(やその他)に関する情報が、KDEコントロールセンターの"Info Centre"セクションで見つかるということです。
 350 このインターフェースは、シリアルナンバー、ベンダIDなどのような情報を表示します。
 351 GUI的なやり方が好ましいなら、こちらを調査したいと思うでしょう。<br /><br />
 352 現在リリースされているGNOMEボリューム管理は、実デバイスとしてシンボリックリンクノードを扱うことができません。
 353 上記で説明したのとは反対に、<i>NAME</i>パラメータにユーザ指定の名前を指定して、<i>SYMLINK</i>パラメータに%kを指定しようと思うかもしれません。<br /><br />
 354
 355 <a href="#multiple-symlinks">複数SYMLINK形式</a>を使えば、ユーザ指定ルールが初期設定を上書きする仕様に対処できます。
 356
 357 </font>
 358
 359 <a name="multiple-symlinks"></a>
 360 <h2>複数SYMLINK形式の使い方</h2>
 361 最近取り入れられた機能の一つに、<i>NAME</i>を指定せずに、複数の<i>SYMLINK</i>キーを単純に指定するルールが書けるようになったことがあります。
 362 これで、ユーザ指定ルールがudevの初期設定を実質的に無効にする問題を避けることができます。<br /><br />
 363
 364 そのルールを以下に取り上げます。<br />
 365 <blockquote><pre>KERNEL="hdc", SYMLINK="dvd"</pre></blockquote>
 366 udevはこのルールを見つけると、記憶しておきます。
 367 そして、<i>NAME</i>パラメータも含む同一デバイスに一致する別のルールを見つけたときに、その<i>NAME</i>パラメータで指定されているノードに加え、両方のルールにある<i>SYMLINK</i>パラメータで指定されているシンボリックリンクも作成します。<br />
 368 実際問題として、udevは私の<i>hdc</i>デバイスのノードを命名する際に、いつものようにブロックデバイス用の初期設定ルールを使い、追加の私個人指定の"dvd"シンボリックリンクを作成します。<br /><br />
 369
 370 普通のルールと同様に、udevが<i>NAME</i>パラメータを指定しているルールを見つける<i>前に</i>この形式のルールを見つけたときだけ有効になります。<br /><br />
 371
 372 <a name="mode-owner-group"></a>
 373 <h2>所有権とパーミッション制御</h2>
 374 作成されるデバイスノードの名前付け制御と同様に、udevルールは、そのデバイスノードの所有権とパーミッション属性の制御も可能にします。<br /><br />
 375
 376 <i>GROUP</i>キーは、どのunixグループにデバイスノードを所有させるかを定義できます。
 377 ここにudevの初期設定から例を示します。
 378 この例は、フレームバッファ(fb)デバイスを<i>video</i>グループにするように定義しています。
 379
 380 <blockquote><pre>KERNEL="fb[0-9]*", NAME="fb/%n", SYMLINK="%k", GROUP="video"</pre></blockquote>
 381
 382 おそらくあまり使えない<i>OWNER</i>キーは、どのunixユーザにデバイスノードを所有させるかを定義できます。
 383 フロッピーデバイスを"john"の所有にする場合のちょっと変な状況を仮定すると、次のように使います。
 384 <blockquote><pre>KERNEL="fd[0-9]*", OWNER="john"</pre></blockquote>
 385
 386 上記のルールには、<i>NAME</i>や<i>SYMLINK</i>が一つも指定されていないことがわかるでしょう。
 387 これは、udevが、フロッピーノードをjohnの所有にしたいということを記憶しておき、フロッピーデバイスノードに対する<i>NAME</i>が定義されたルールを見つけると、所有者を適用する点で、<a href="#multiple-symlink">複数シンボリック形式</a>に似ています。<br /><br />
 388 上で記述した形式を使用すると、もっと華麗なこともできます。
 389 udevの初期設定では、すべてのサウンドデバイスノードが"audio"グループによって所有されるように定義するのに以下のルールを使用しています。
 390 <blockquote><pre>SUBSYSTEM="sound", GROUP="audio"</pre></blockquote>
 391
 392 これに続くサウンドデバイスに名前を付ける全てのルールに<i>GROUP="audio"</i>キーをやたらと指定する必要をなくします。<br /><br />
 393
 394 udevのデフォルトでは、unixパーミッションに0660(所有者とグループだけが読み書き可能)を持つノードを作成するようになっています。
 395 これは、<i>/etc/udev/udev.conf</i>の中の<b>default_mode</b>設定によって設定されています。
 396 デバイスノードにデフォルトパーミッションを適用したくない場合もあるかもしれません。幸いにして、ルールに<i>MODE</i>割当てキーを使うことで簡単にデフォルト設定より優先させることができます。
 397 例として、以下のルールはinotifyノードが全てのユーザに読み書き可能になるように定義しています。
 398
 399 <blockquote><pre>KERNEL="inotify", NAME="misc/%k", SYMLINK="%k", MODE="0666"</pre></blockquote>
 400
 401 <a name="example-printer"></a>
 402 <h2>例: 著者所有のUSBプリンタ向けのルールの書き方</h2>
 403 私は、プリンタを接続した後、ルールを書くために/sysディレクトリから関連する位置を探し始めました。
 404 どこにも見つからなかったのですが、私のプリンタにデバイスノード<i>/dev/lp0</i>が割り当てられていることに気づきました。
 405 udevinfoは、便利なpathを指定すると以下のように教えてくれます。
 406 <blockquote><pre># udevinfo -q path -n /dev/lp0
 407 /class/usb/lp0
 408 </pre></blockquote>
 409 "udevinfo -a -p /sys/class/usb/lp0"を実行すると、通常通りに多くの情報を提供してくれます。
 410 デバイスを識別する以下の固有の情報を選択しました。
 411 <blockquote><pre>looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3':
 412 BUS="usb"
 413 SYSFS{manufacturer}="EPSON"
 414 SYSFS{product}="USB Printer"
 415 SYSFS{serial}="L72010011070626380"
 416 </pre></blockquote>
 417
 418 この場合のudevルールは以下のようになります。
 419 <blockquote><pre>BUS="usb", SYSFS{serial}="L72010011070626380", NAME="%k", SYMLINK="epson_680"</pre></blockquote>
 420
 421 そうすると、私のプリンタのノードは<i>/dev/lp0</i>(または、別のプリンタが前もって接続されている場合は<i>/dev/lp1</i>)で存在し、<i>/dev/epson_680</i>は<b>常に</b>そのプリンタのためのデバイスノードを指します。<br /><br />
 422
 423 <a name="example-camera"></a>
 424 <h2>例: 著者所有のUSBストレージ方式対応デジカメ向けのルールの書き方</h2>
 425
 426 <font size="2">簡単な説明: 私のカメラは外付けSCSIハードディスクとして認識されます(USBハードディスクやフラッシュメモリカードリーダのようなデバイスにも使用されるusb-strageドライバを使います)。
 427 そして、そのディスク上のパーティションをマウントして、画像ファイルをコピーできます。すべてのカメラがこのように動作するわけではありません。ほとんどのカメラは、画像ファイルを扱うために、さらにソフトウェア(gphoto2など)を必要とします。</font><br /><br />
 428
 429 これにはちょっとしたコツがあります。私のカメラが接続されると、デフォルトでいくつかのノードが作成されます。
 430 <i>/dev/sda</i>や<i>/dev/sda1</i>、<i>/dev/sg1</i>さえも作成されるかもしれません。
 431 <b>この例が示しているものは重要です。もしルールが上手に指定されなければ、上記3つのノードすべてに一致することがありえます。</b><br /><br />
 432
 433 sda1は、私がマウント用に<i>/dev/camera</i>として使用しようと思うノードです。
 434 udevinfoはsda、sda1、sg1の間に利用できそうな差異は何も提示してくれません。
 435 これら3つのノードを区別するために信頼できる方法は、<i>KERNEL</i>名を見ることであると私は判断しました。<br /><br />
 436
 437 <i>KERNEL="sd?1"</i>のようなキーは、"sda1"、"sda1"、"sdc1"のようなKERNEL名に一致し、そして同様に重要なことに、それは、sda、sdb、sg1のようなKERNEL名に<b>一致しない</b>であろうということです。
 438 このようなキー指定には、<i>/dev/sda</i>や<i>/dev/sg1</i>ノードに一致させないという目的があります。
 439 対象のデバイスはデジタルカメラです。その上ではfdiskやその類の操作をしようなんて夢にも思わないので、私にとってこれらの2つのノードは、まったく使いものになりません。
 440 このキーは<i>/dev/sda1</i>ノードを捕捉しようとします。これはマウント可能なので、使いものになります!<br /><br />
 441
 442 このノード(sda1)は、ブロックデバイスとして扱われるので、<i>/sys/block</i>から探すことは、作業を始めるのに向いています。<br /><br />
 443
 444 私の環境での<i>/sys/block</i>には、<i>sda</i>というディレクトリがあります。
 445 <i>/sys/block/sda</i>には、<i>sda1</i>というディレクトリがあります。
 446 これら両方のディレクトリに<i>dev</i>ファイルがあるので、そこで<i>udevinfo</i>を実行できます。
 447 以下を実行すると、私のカメラとそれが接続されているUSBポートに関するたくさんの情報を表示してくれます。
 448
 449 <blockquote><pre># udevinfo -a -p /sys/block/sda/sda1</pre></blockquote>
 450
 451 udevinfoの出力に、以下のちょっと役に立つ意味がわかりやすい情報を見つけました。<blockquote><pre>SYSFS{product}="USB 2.0M DSC"</pre></blockquote>
 452
 453 よってこれで私のルールを書くことができます。ルールを完全にするために、BUSキーも加えます(これもudevinfoの出力で見つかります)。
 454 <blockquote><pre>BUS="usb", SYSFS{product}="USB 2.0M DSC", KERNEL="sd?1", NAME="%k", SYMLINK="camera"</pre></blockquote>
 455
 456 こうして、私のカメラを接続すると、<i>/dev/sda1</i>(もしくは、sda1が利用できないなら、<i>/dev/sdb1</i>になるかもしれません)という名前で、<b>常に</b>間違いなく<i>/dev/camera</i>からリンクされます。
 457 /dev/sda(もしくはsdb)ノードは、いつものようにまだ出現します。
 458 しかし私が指定する不変の"camera"シンボリックが、マウント可能パーティションを指しているということが重要です。<br /><br />
 459
 460 <a name="usbstorage-extra"></a>
 461 <h2>USBストレージ向けルールの書き方に関する追記</h2>
 462
 463 大容量のUSBハードディスクを所持する<i>Carl Streeter</i>が、<i>/dev/sda</i>ノードが役に立たなかった私のデジタルカメラの例とは違った説明をメールしてきました。
 464 <i>/dev/sda</i>のようなノード上で<i>fdisk</i>や<i>hdparm</i>などのツールをちょくちょく使う必要があることを指摘しています。<br /><br />
 465
 466 以下にCarlのルールを示します。
 467 <blockquote><pre>BUS="usb", KERNEL="sd*", SYSFS{product}="USB 2.0 Storage Device", NAME="%k", SYMLINK="usbhd%n"</pre></blockquote>
 468
 469 このルールは、以下のようなシンボリックリンクを作成します。
 470 <ul>
 471 <li><i>/dev/usbhd</i> - fdiskすることができるノード</li>
 472 <li><i>/dev/usbhd1</i> - 一つ目のパーティション (マウント可能)</li>
 473 <li><i>/dev/usbhd2</i> - 二つ目のパーティション (マウント可能)</li>
 474
 475 </ul>
 476 Carlとはマウント不可の<i>/dev/sda</i>ノードが必要かどうかは、状況と対象のデバイスに依存するということで共通認識を持っています。
 477 どちらの設定方法にしろ都合のよい方を使用してください。<br /><br />
 478 これとは別の複雑な状況として、複数のスロットを持つUSBストレージカードリーダを持っている場合があります。
 479 新しいカードが刺されたり抜かれたりしたときに、一般的にこのような種類のデバイスはその情報を通知しません。
 480 よって、リーダが接続されている間に未使用スロットにカードを刺しても、マウントする必要がある追加のデバイスノードは、作成されないでしょう!<br />
 481 この問題は、他のUSBディスクにも当てはまります。
 482 例えば、新しいパーティションを作成した場合、デバイスを再接続するまで、新しいパーティションノードは出現しないでしょう。<br /><br />
 483 udevは、これに対する一つの解決方法を提供します。
 484 ブロックデバイスのすべてのパーティション用のノードを作成することができます。
 485 指定したすべてのルールに対して、ブロックデバイスで16個のパーティションノードを作成します。
 486 これをするには、以下に示すように単にNAMEキーを修正します。<br />
 487
 488 <blockquote><pre>BUS="usb", SYSFS{product}="USB 2.0 Storage Device", NAME{all_partitions}="usbhd"</pre></blockquote>
 489
 490 こうすることで、usbhd、usbhd1、usbhd2、usbhd3、...、usbhd15というノードが作成されるでしょう。<br /><br />
 491
 492 <a name="example-cdrom"></a>
 493 <h2>例: 著者所有のCDドライブ向けの有用なルールの書き方</h2>
 494 私のPCには二つのCDドライブがあります。一つは、DVD読み込み対応で、一つはCD読み書き対応のものです。
 495 DVDのノードはhdcで、CDRWのノードはhddです。
 496 あえてシステムの結線を変更する場合を除いて、これを変更するつもりはありません。<br /><br />
 497
 498 でも、利便性のために<i>/dev/dvd</i>や<i>/dev/cdrw</i>のようなノードを好む人が(私自身も含めて)います。
 499 これらドライバの"hdX"の値がわかっているので、ルールを書くのは簡単です。
 500 以下の例は、それだけで自明でしょう。
 501 <blockquote><pre>BUS="ide", KERNEL="hdc", NAME="%k", SYMLINK="dvd cdroms/cdrom%n"
 502 BUS="ide", KERNEL="hdd", NAME="%k", SYMLINK="cdrw cdroms/cdrom%n"
 503 </pre></blockquote>
 504
 505 <font size="2">デフォルトの50-udev.rulesファイルにブロックデバイス用の名前を生成するスクリプトを実行するルールがあることに気が付くかもしれません。
 506 これに惑わされないでください。やはりユーザ指定のルールは、デフォルトルールの<b>前に</b>処理されるファイルに設定するので、デフォルト設定は、ルールを設定済みのハードウェアに名前をつけるときには使用されません。</font><br /><br />
 507
 508 <a href="http://www.reactivated.net/example-pilot"></a>
 509 <h2>例: USB Visor Palm Pilot向けのルールの書き方</h2>
 510
 511 これらのデバイスは、USBシリアルデバイスのように動作します。よってデフォルトでは<i>ttyUSB1</i>ノードだけが得られます。
 512 ユーザスペースのpalmユーティリティは、<i>/dev/pilot</i>があることを前提としています。
 513 よってそのノードを作成するルールを使う必要があります。
 514 以下のルールはこれを行います。<br /><br />
 515
 516 <blockquote><pre>BUS="usb", SYSFS{product}="Palm Handheld", KERNEL="ttyUSB*", SYMLINK="pilot"</pre></blockquote>
 517
 518 この状況に関する有用な議論がある<a href="http://www.clasohm.com/blog/one-entry?entry%5fid=12096">Carsten Clasohm's blog entry</a>(訳注: Carsten Clasohmのブロブ)から応用しました。
 519 さらに個々の設定に合わせるために、上記ルールに<a href="#mode-owner-group">所有権とパーミッションキー</a>を追加したいと思うかもしれません。<br /><br />
 520
 521 <a name="example-iface"></a>
 522 <h2>例: 著者所有のネットワークインターフェースに名前を付けるルールの書き方</h2>
 523 最近のバージョンのudevにある興味深い新しい機能に、<i>nameif</i>ユーティリティのように、ネットワークインタフェースの名前を付け直す機能があります。
 524 ネットワークインターフェースは、<i>/dev</i>に出現しませんが、一般的にはそれらは名前によって参照されます(例えば、<i>ifconfig</i>で使用される場合)。
 525 ネットワークデバイスには様々ありますが、ルールを書く工程はほとんど同じです。<br /><br />
 526 やはりudevinfoはルールを書く手がかりになります。
 527 以下は私の"eth0"のネットワークデバイスの名前を変更したい場合の例です(以下の出力結果は省略されています)。
 528 <blockquote><pre># udevinfo -a -p /sys/class/net/eth0/
 529   looking at class device '/sys/class/net/eth0':
 530     SYSFS{address}="00:52:8b:d5:04:48"
 531 </pre></blockquote>
 532 すべてのネットワークアダプタには固有のMACアドレスがありますので、ルールを書く場合にはこれを使うことを選択しました。
 533 この値は、ネットワークカードを変更しない限り変更がありません。
 534 以下に一つ警告があります。
 535 大文字小文字を区別しますので、必ず(上記のように)udevinfoから取得したMACアドレスを使ってください。
 536 <i>ifconfig</i>のようなユーティリティを使う場合は、それらは大文字を使うので、気をつけてください。<br /><br />
 537
 538 ルールの例を以下に示します。
 539 <blockquote><pre>KERNEL="eth*", SYSFS{address}="00:52:8b:d5:04:48", NAME="lan"</pre></blockquote>
 540 このルールを有効にするためにネットワークドライバをリロードしなければならないでしょう。
 541 モジュールをアンロードして再度ロードするか、もしくは単にシステムをリブートすればよいです。
 542 "eth0"ではなく"lan"を使うようにシステムを構成しなおす必要もあります。
 543 私の場合、eth0を参照するものすべてを完全に削除しないで、これを進めてしまい、少々苦労をしました。<br />
 544 これが完了すれば、<i>ifconfig</i>やそれに似たユーティリティのどれにでも"eth0"の代わりに"lan"を使えるはずです。<br /><br />
 545
 546 <a name="tips"></a>
 547 <h2>SYSFS内におけるudevinfoを実行すべき場所を探すためのコツ</h2>
 548 <font size="2">ここではより多くのデバイス固有のコツを求めています。
 549 提供できることならなんでも<a href="#author">連絡してください</a>。</font>
 550
 551 <ul>
 552 <li>ルールを書こうとしているデバイスに対し、すでに/devの下にデバイスノードが作成されているなら、運がよいです!
 553 適切な/sysのパスを得るために、次のコマンドを実行してください。<i>udevinfo -q path -n /dev/ノード名</i></li>
 554 <li>ルールを書く手間を軽くするために、常にudevinfoを使用してください。
 555 /sys/blockや/sys/classの下を参照するために、常にudevinfoを使用してください(別のところから、チェイン情報を読むことはありません)。</li>
 556 <li>何も手がかりがなければ、/sysの下のすべて"dev"ファイルを探すために、次のコマンドを使用してくだい(udevinfoは、このファイルがあるディレクトリ上でのみ動作します。)。find /sys -iname dev</li>
 557 <li>対象のデバイスが、フラッシュカードリーダや、USBフラッシュドライブ、/dev/sdXが作成されるUSBストレージとして振舞うデジタルカメラの場合、/sys/block/sdXを探してみてください。</li>
 558 <li>上記の状況に該当する場合、必ずsdXとsdX1とを区別して下さい。sdX1に一致するキー<i>KERNEL="sd?1"</i>もしくは、sdXに一致する<i>KERNEL="sd?"</i>で区別できます。</li>
 559 <li>/dev/lpXとして作成されるUSBプリンタについては、/sys/class/usb/lpXから探すべきです。</li>
 560
 561 <li>USBスキャナドライバは、最近カーネルから削除され、(SANEパッケージの一部として)ユーザスペースで再実装されました。
 562 特定のカーネルドライバに依存しないように、この種のハードウェア用のルールを書いてはいけません(し、書けないでしょう)。</li>
 563 <li>あいにくカーネルはsysfsですべてのデバイスの情報を開示するわけではありません。
 564 よって、まだ一部のデバイスに対してはルールを簡単に書くことができません。
 565 2004年2月20日時点で、udevの作者はsysfsに未対応のドライバが162個残っていると言っています。</li>
 566 </ul>
 567
 568 <a name="debugging"></a>
 569 <h2>ルールのデバッグ方法</h2>
 570
 571 ルールを書き終わって忘れずに<b>udevstart</b>を実行しても、有効にならないなら、それをデバッグするのには二つの方法があります。<br /><br />
 572
 573 <i>/etc/udev/udev.conf</i>には、<b>udev_log</b>オプションがあります。
 574 そのオプションを<i>yes</i>に設定すると、udevはどのノードにどのルールを適用したかに関するいくつかの役に立つ情報をシステムロガーに出力します。
 575 そのログ情報は、ほとんどの場合/var/log/messagesにあるでしょう。<br /><br />
 576
 577 さらに、ユーザが作成したいノードの<i>sysfs</i>におけるパスを調べたいなら、ノードに対しudevがするはずであったことを一つずつ追って確認するために、<b>udevtest</b>を使用できます。
 578 以下に例を示します。
 579
 580 <blockquote><pre># udevtest /sys/class/sound/dsp/
 581 version 056
 582 looking at '/class/sound/dsp/'
 583 opened class_dev-&gt;name='dsp'
 584 configured rule in '/etc/udev/rules.d/50-udev.rules[132]' applied, added symlink '%k'
 585 configured rule in '/etc/udev/rules.d/50-udev.rules[132]' applied, 'dsp' becomes 'sound/%k'
 586 creating device node '/dev/sound/dsp', major = '14', minor = '3', mode = '0660', uid = '0', gid = '18'</pre></blockquote>
 587
 588 <b>udevtest</b>は、デバッグ/テストだけをするツールです。たとえ作成しているように表示しても、実際にはデバイスノードを作成しません!<br /><br />
 589
 590 <a name="author"></a>
 591 <h2>著者と謝辞</h2>
 592 この文書はDaniel Drake &lt;<a href="mailto:dan@reactivated.net">dan@reactivated.net</a>&gt;<br />によって書かれました。
 593 ご意見ご感想などなんなりと送ってください!<br /><br />
 594
 595 Copyright (C) 2003-2005 Daniel Drake<br />
 596 この文書は<a href="http://www.gnu.org/licenses/gpl.html">GNU General Public License, Version 2</a>の下に公開されています。
 597
 598 </body></html>