次のページ 前のページ 目次へ

4. どのように動作するか

SANE アプリケーションをビルドする際、libsane.so という共有ライブラリがリン クされている必要があります。実際には、libsane.so は SANE ドライバ群の一つ へのシンボリックリンクに過ぎません。どの SANE ドライバも同じインタフェース を提供するので、いつでも libsane.so へのシンボリックリンクを変更できますし、 アプリケーションが使用しているドライバを効果的に変更できます。 全てのアプリケーションをリンクし直すことなくドライバをアップグレードできる ため、ある意味これは便利ですが、スキャンデバイスを切替えたい時はシンボリッ クリンクを変更しなければならず、かなり不便です。 このため SANE は、dll および net という 2 つの仮想デバイスドライバをサポ ートしています。これらは仮想ドライバです − なぜなら物理的デバイスに話しか けるのではなく、図 6 に示すように他の SANE ドライバと話すからです。

<< 図 6: 取りうる SANE 階層 >>

マシン A にとって、libsane.so のシンボリックリンクは dll 仮想ドライバ (libsane-dll.so と呼ばれる)を指しています。仮想ドライバは他の SANE ドラ イバにアクセスするためにダイナミックリンクライブラリ(dll)を使用します。 例示した図では dll は pnm, mustek, net ドライバを使うために設定されています。

net ドライバもやはり仮想ドライバで、これはマシン B で動作している SANE デーモン(saned)に接続することにより、リモートスキャナへのアクセスを提供 します。さて、マシン B は、他のいくつかのドライバにアクセスするために 再び dll を使用します。ご想像のように、システム管理者は、マシン A と B を 正しく設定しないといけません。

libsane.so を dll 仮想ドライバへのシンボリックリンクとするのは、普通に行わ れるやり方です。でも net 仮想ドライバへのリンクにしたり、単純に mustek ドラ イバへのリンクにしたりもできない理由はないはずです。 もちろん、例えば mustek にリンクさせた場合には、アプリケーションは mustek の ドライバにしかアクセスできなくなるでしょう。 でも、これは特定の環境においては完全に合理的であるかもしれません。

このアプローチは大変柔軟ですが、興味深い質問が出てきます。 このような環境でデバイスの名前をどうやってつけるのでしょう? 答えは、リアルドライバは全てそれ自身の名前のスペースを持っている、です。 例えば、Mustek と HP ドライバはデバイスを制御する /dev/scanner のような Unix スペシャルデバイスのパスを使います。

仮想ドライバには、もう少し面白いことがあります。 dll は各ドライバ名がユニークであることを保証しなければならないので、 各々の従属デバイス名と従属ドライバ名をコロンで区切ったものを接頭辞として つけます。従って、マシン A では mustek のスキャナは mustek:/dev/scanner と呼ばれます。net 仮想ドライバも同様に、リモートデバイス名とリモートホ スト名を接頭辞としてつけます(やはりコロンがセパレータとして使われます)。

例えば、マシン B の HP スキャナ1 は、net:B.domain.com:hp:/dev/scanner1 という名前でマシン A に現れます。野暮ったい名前ですが、名前に含まれる情報 は実際に極めて有用です。

デバイス名は SANE の階層を通して個々のデバイスへ割り振られます (本質的には、Unix のパス名に似ています)。 例えば、マシン B がダウンしたことが分かれば、 net:B.domain.com:hp:/dev/scanner1 も同じようにダウンしていることは、明白 です。

これらの名前がすごく嫌なら、ユーザまたはシステム管理者が、アプリケーション を簡潔なエイリアスで定義することもできます。 例えば、ユーザがアプリケーションで上記デバイス名を(初心者には分かり易い) `HP Scanner 1' にリネームできます。


次のページ 前のページ 目次へ