大半の UNIX ライクなオペレーティングシステムと同じように、 Linux はシリアルコンソールが、 ダムモデムにつながっているものと思っています。 ダムモデムは最近はあまり見かけません。 見かけるとすれば、たぶん ISDN のターミナルアダプタや、あるいは衛星回線の地上端末といった、 風変わりなハードウェアだけでしょう。
ダムモデムはハードウェアを使って設定します。 Figure 12-1 には、 仮想のダムモデムのフロントパネルを示しています。 実際は、速度とモードの設定には、 ジャンパーや DIP スイッチを使うようです。
Figure 12-1. ダムモデムのフロントパネル
+-----------------------------+ | | | SPEED MODE | | [ ] 300 [ ] Originate | | [ ] 600 [X] Answer | | [ ] 2400 | | [X] 9600 | | | +-----------------------------+ |
モデムの速度は必要なビットレートに設定します。 この例では 9600 bps です。モデムのモードは "Answer" に設定します。 つまり、着信を待ち、そしてその着信に応答するのです。
RS-232 の制御ラインである "Data Terminal Ready" が落ちていると、モデムは着信した電話には応えません。 コンピュータの電源が切れているとか、 あるいはコンピュータのシリアルインタフェースが、 まだ初期化されていないのです。 DTR が上がってしまえば、 モデムは着信する電話に応えます。
電話が着信し接続が確立されてしまえば、モデムは "Data Carrier Detect" 制御ラインを上げます。 DCD が上がっている時に受信したデータだけが有効になります （DCD がアサートされていない時にダムモデムから受信したデータは、 おそらくラインノイズです）。 そして、DCD が上がっている時だけ、 送信データがリンクを通じて伝送されます。
Linux コンピュータの getty は、 DCD が上がってくるのをずっと待っていたので、 getty はユーザーを喜んで迎え、 ログインを要求します。
ユーザーがログインしてデータが流れる一方で、モデムとコンピュータの間で "Clear to Send" と "Ready to Send" を使い、 データの送出が早過ぎないようにしています。 文字を受けとる時間が無いほどコンピュータが忙しい場合、 コンピュータは "Clear to Send" を落とします。 逆にモデムが忙し過ぎて文字を受けとれない場合は、 モデムが "Ready to Send" を落とします。
ユーザーが電話を切ると、"Data Carrier Detect" が落ち、 その着信しているセッションに関係するすべてのプロセスに、 ハングアップシグナルが送られます。
あるいはユーザーがログアウトしてもかまいません。シェルが死ぬと、 コンピュータは "Data Terminal Ready" を落とし、 その結果モデムがハングアップします。 getty が再度 "Data Terminal Ready" を上げると、 モデムは着信を受け付けます。
"Data Set Ready" についてはまだ説明していませんでした。 このラインはモデムの電源が切れていたり、 モデムがまだ初期化されていない場合に落ちます。 DSR が落ちている時は、 他の信号はすべて未定義状態です。 例えば、DSR が落ちている状態で、 DCD が "フロートして" 上がった場合、 ソフトウェアは、 DCD がアサートされていないという想定で、動作するようにしてください。