役に立つと思われるシリアル関連のちょっとしたテクニックを紹介します。
テキスト端末では EIA-232 は十分高速ですが、許されるケーブル長が短す ぎることはよくあります。この問題は平衡型伝送技術により解決します。 テキスト端末で平衡型伝送を行うための一般的な方法は、シリアル回線に 2 つのラインドライバをインストールして、非平衡型から平衡型への変換(およ び逆変換)を行うことです。これは特殊な機器であり、新しく買うとなると高 価でしょう。
IBM 8514 ボード(など)の I/O アドレスは信じられないことに 0x?2e8
(? は 2, 4, 8, 9 のいずれか)です。シリアルポートがアドレスを展開する時
に 16 進値の先頭の 0 である桁を無視する(多くのシリアルポートはそのよう
に動作します)場合には、これは 0x2e8 にある ttyS3 の I/O アドレス
と衝突します(ただしシリアルポートがうまく設計されていれば衝突しないは
ずです)。このアドレスで ttyS3 を使おうとしている人には悪い知らせ
です。これとは別の問題で Linux は ttyS3 にある内蔵モデムを検出で
きませんが、setserial を使ってこのアドレスに ttyS3 を置
けば、モデムはうまく動作するでしょう。
これは割り込みと UART の状態レジスタが競合するという問題です。UART のトランスミッタがバイトデータの送信を終え、UART の送信バッファが空に なると割り込みが発行されます(そして次のバイトデータを待ちます)。しかし UART の状態レジスタはの更新速度は、これが十分反映されるほど速くありま せん。その結果、割り込みサービスルーチンが高速なチェックを行うと、何も 起こっていないと(間違って)判断します。したがって、次に転送すべきバイト データはシリアルポートに送られず、UART のトランスミッタは届くことのな いバイトデータを虚しく待ち続けることになります。割り込みサービスが状態 レジスタをチェックするまでの待ち時間がもう少し長ければ、実際の状態が反 映され、全てがうまく行くはずなのですが…。
シリアルドライバにパッチを当てることにより、この問題を解決しようという 提案もあります。しかし、欠陥ハードウェアに対応するために Linux にパッ チを当てるべきでしょうか? しかも問題ないハードウェアでの性能が落ちるか もしれないのに。
ロックファイルは単に、特定のデバイスが使用中であることを示すファイルで
す。このファイルは /var/lock に置かれます。以前は
/usr/spool/uucp に置かれていました。Linux では、ロックファイ
ルの名前は LCK..name のようになります。ここで name はデ
バイス名か、UUCP のサイト名です。あるプロセスがこのロックファイルを作
ると、そのデバイスに排他的にアクセスできるようになります。例えば、モデ
ムを使ってダイアルアウトを行うと、誰かがモデムを既に使っていることをロッ
クファイルが他のプロセスに伝えます。ロックファイルの内容は主に、デバイ
スをロックしているプロセスの ID です。ほとんどのプログラムはロックファ
イルを参照し、プロセステーブルを見てそのデバイスをロックしているそのプ
ロセスを調べることにより、そのロックがまだ有効かどうかを調べようとしま
す。ロックファイルが有効であることが分かれば、そのプログラムは終了しま
す(終了するはずです)。ロックが無効ならば、無効なロックファイルを削除し
てそのデバイスを使い、新しく独自のロックファイルを作るプログラムもあり
ます。単にそのデバイスが使用中であると表示して終了するプログラムもあり
ます。
物理的には同じシリアルポートが異なる 2 つの名前を持つ(例: ttyS0 と cua0)を持っているために問題が起こることもあります。ロックをチェックす るソフトウェアは ttyS と bua を調べますが、cua を使わないことにすれば この点に関する話は簡単になります。これ以外にも、同じデバイスに複数の名 前を付けることも問題を起こす原因となります。