Loading article…
Unix系オペレーティングシステムでは、デバイスファイル、デバイスノード、または特殊ファイルは、ファイルシステム上で通常のファイルのように表示されるデバイスドライバへのインターフェースです。DOS 、OS/2、Windowsにも特殊ファイルが存在します。これらの特殊ファイルにより、アプリケーションプログラムは標準入出力システムコールを介してデバイスドライバを使用することで、デバイスと対話できます。標準システムコールを使用することで、多くのプログラミング作業が簡素化され、デバイスの機能や特性に関係なく、一貫したユーザー空間I/Oメカニズムが実現します。
デバイスファイルは通常、プリンターやシリアルポートなどの標準デバイスへのシンプルなインターフェースを提供しますが、ディスクパーティションなど、それらのデバイス上の特定の固有リソースにアクセスするためにも使用できます。さらに、デバイスファイルは、データシンクや乱数発生器など、実際のデバイスとは直接関係のないシステムリソースにアクセスする際にも役立ちます。
Unix系オペレーティングシステムには、文字特殊ファイルとブロック特殊ファイルという2種類のデバイスファイルがあります。両者の違いは、オペレーティングシステムとハードウェアが読み書きするデータ量にあります。これらをまとめてデバイス特殊ファイルと呼び、デバイスに接続されていないものの通常のファイルでもない名前付きパイプとは対照的です。
MS-DOS はUnix から特殊ファイルの概念を借用しましたが、デバイスという名前に変更しました。[ 1 ] MS-DOS の初期バージョンはディレクトリ階層をサポートしていなかったため、デバイスは、フォルダ名やファイル名として使用できない予約語を名前にすることで、通常のファイルと区別されました。たとえば、単語は予約語です。これらはCP/MCONとのある程度の互換性のために選択され、後方互換性のために最新の Windows にも残っています。名前は大文字と小文字を区別しないため、「con」、「Con」、「CON」はすべて無効な名前です。
Windows XPでは、実行コマンドに「Con」と入力すると、「このファイルには、この操作を実行するための関連付けられたプログラムがありません。フォルダー オプション コントロール パネルで関連付けを作成してください。」というエラー メッセージが表示されます。予約名を使用してファイルまたはフォルダーの名前を変更しようとすると、通知やエラー メッセージが表示されずに、ファイルまたはフォルダーは以前の名前 (または「新しいフォルダー」、「新しいテキスト ドキュメント」など) に静かに戻ります。[ 2 ] Windows Vista以降では、ファイルまたはフォルダーに予約名を使用しようとすると、「指定されたデバイス 名が無効です。」というエラー メッセージが表示されます。[ 2 ]
Unix ライクなシステムでは、ほとんどのデバイス ファイルは、従来 にマウントされた仮想ファイルシステム/devの一部として管理され、場合によっては制御デーモンに関連付けられています。このデーモンは、実行時にハードウェアの追加と削除を監視し、カーネルによって自動的に行われない場合はデバイス ファイルシステムに対応する変更を行い、場合によってはシステム スペースまたはユーザー スペースのスクリプトを呼び出して特別なデバイス ニーズを処理します。FreeBSD 、DragonFly BSD、およびDarwin には専用のファイルシステムdevfsがあります。デバイスノードは、カーネル スペースでこのファイルシステムによって自動的に管理されます。Linux には、以前は同様のdevfs実装がありましたが、後に放棄され、バージョン 2.6.17 以降削除されました。[ 3 ] Linux は現在、主にudevとして知られるユーザー スペース実装を使用していますが、多くのバリエーションがあります。
Solaris Containersなど、 chrootプロセス分離をサポートする Unix システムでは、通常、各 chroot 環境は独自の を必要とします。これらのマウント ポイントは、ホスト OS のグローバル ファイルシステム ツリー内のさまざまなノードで表示されます。 の chroot インスタンスに組み込まれるデバイス ノードを制限することで、chroot 環境によってハードウェア分離を強制できます (プログラムは、認識も名前も付けられないハードウェアに干渉することはできません。これは、 Unixファイルシステムのパーミッションよりもさらに強力なアクセス制御です)。/dev/dev
MS-DOS は、各デバイス ファイルを排他的にオープンすることでハードウェア デバイスの競合を管理していました ( terminate-and-stay-resident プログラムを参照)。既に使用されているデバイスにアクセスしようとするアプリケーションは、デバイス ファイル ノードを開くことができないことに気づきます。同時アクセスに関しては、Unix および Linux でさまざまなデバイス ドライバセマンティクスが実装されています。[ 4 ]
デバイス ノードは、オペレーティングシステムのカーネルが既に割り当てたリソースに対応します。Unix では、これらのリソースをメジャー番号とマイナー番号[ 5 ]で識別し、両方ともノードの構造の一部として格納されます。これらの番号の割り当ては、異なるオペレーティングシステムや異なるコンピュータ プラットフォームで一意に行われます。一般的に、メジャー番号はデバイス ドライバを識別し、マイナー番号はドライバが制御する特定のデバイス (複数ある場合もある) を識別します。[ 6 ]この場合、システムはマイナー番号をドライバに渡すことがあります。ただし、動的な番号割り当てが存在する場合、そうでない場合があります (たとえば、FreeBSD 5 以降)。
他の特殊ファイルタイプと同様に、コンピュータシステムは標準システムコールを使用してデバイスノードにアクセスし、通常のコンピュータファイルと同様に扱います。デバイスファイルには2つの標準タイプが存在しますが、残念ながら歴史的な理由からその名称は直感に反するものであり、結果として両者の違いに関する説明が誤っていることがよくあります。
文字特殊ファイルまたは文字デバイスは、バッファリングなしでハードウェアデバイスに直接アクセスできるようにします。ただし、プログラムが一度に1文字ずつ読み書きできるとは限りません。それはデバイスによって異なります。たとえば、ハードディスクの文字デバイスでは、通常、すべての読み書きがブロック境界にアラインメントされている必要があり、1バイトの読み取りはまず許可されません。
キャラクタデバイスは、ブロックベースのハードウェア用のキャラクタデバイスでは、通常、プログラムが整列されたブロックを読み書きする必要があるという事実に関する混乱を避けるために、RAWデバイスと呼ばれることもあります。
ブロック特殊ファイルまたはブロックデバイスは、ハードウェアデバイスへのバッファ付きアクセスを提供し、ハードウェアデバイスの詳細からある程度の抽象化を提供します。[ 7 ]文字デバイスとは異なり、ブロックデバイスでは、プログラマは常に任意のサイズ（単一の文字/バイトを含む）および任意のアライメントのブロックを読み書きできます。欠点は、ブロックデバイスはバッファ付きであるため、書き込まれたデータがカーネルのバッファから実際のデバイスに渡されるまでにどれくらいの時間がかかるか、また、2 つの別々の書き込みが物理デバイスにどのような順序で到着するかをプログラマが知らないことです。さらに、同じハードウェアが文字デバイスとブロックデバイスの両方を公開している場合、文字デバイスを使用するクライアントがブロックデバイスのバッファで行われた変更を認識しないため、データが破損するリスクがあります。
ほとんどのシステムは、ハードディスクなどのハードウェアを表すためにブロックデバイスとキャラクタデバイスの両方を作成します。FreeBSDとLinuxは特にそうではありません。FreeBSDはブロックデバイスのサポートを削除しており[ 8 ] 、Linuxはブロックデバイスのみを作成します。Linuxでブロックデバイスからキャラクタデバイスの効果を得るには、Linux固有のO_DIRECTフラグを使用してデバイスを開く必要があります。
Unix系システム上のデバイスノードは、必ずしも物理デバイスに対応する必要はありません。このような対応関係を持たないノードは擬似デバイスと呼ばれます。擬似デバイスは、オペレーティングシステムによって処理されるさまざまな機能を提供します。最も一般的に使用される（文字ベースの）擬似デバイスには、次のようなものがあります。
POSIX標準では、デバイス特殊ファイルとして/dev/console、/dev/null、/dev/ttyの 3 つだけを要求していますが、 /dev/console が読み取り可能または書き込み可能である必要はありません。[ 9 ]使用可能なシステムでは、これよりもっと多くのファイルが存在する可能性があります。
さらに、 ioctlインターフェースを備えたBSD固有の擬似デバイスには、以下のものも含まれる場合があります。
ノードは、 mknodシステムコールによって作成されます。ノードを作成するためのコマンドラインプログラムも、mknodと呼ばれます。ノードは、通常のファイルシステムシステムコール ( rename、unlink ) およびコマンド( mv、rm )によって移動または削除できます。
一部のUnixバージョンには、/devディレクトリに必要なすべてのデバイスを作成するmakedevまたはMAKEDEVという名前のスクリプトが含まれています。これは、デバイスに静的にメジャー番号が割り当てられているシステム（例えば、カーネルモジュールにハードコーディングされているシステム）でのみ有効です。
FreeBSDなどの他のUnixシステムでは、devfsを介したカーネルベースのデバイスノード管理のみを使用し、手動でのノード作成はサポートしていません。mknod (2)システムコールとmknod(8)コマンドはPOSIXとの互換性を維持するために存在しますが、devfs外で手動で作成されたデバイスノードは全く機能しません。[ 11 ]
/dev階層内の一部のデバイス名には、デバイスの種類を識別するために、以下の接頭辞が使用されます。
一部のオペレーティングシステムでは、いくつかの追加の接頭辞が一般的に使用されるようになっています。
Linuxで使用されるプレフィックスの正規リストは、Linuxデバイスリスト、つまりLinuxオペレーティングシステムに割り当てられたデバイス番号と/devディレクトリノードの公式レジストリに記載されています。 [ 12 ]
ほとんどのデバイスでは、このプレフィックスの後に、特定のデバイスを一意に識別する番号が続きます。Linux では、ハードディスク ドライブの場合、デバイスを識別するために文字が使用され、その後にパーティションを識別するための番号が続きます。したがって、ファイルシステムは、たとえばディスク上の領域を/dev/sda3として「認識」したり、ネットワーク ターミナル セッションを/dev/pts/14に関連付けられていると「認識」したりできます。他の実装では、一般的にディスク デバイス ノードに番号を使用しますが、この場合、ディスク パーティションは/dev/da0p3、/dev/disk1s3などの補助番号で識別されます。
一般的なPCマスターブートレコードを使用するディスクでは、プライマリパーティションとオプションの拡張パーティションのデバイス番号は1から4までですが、論理パーティションのインデックスは、前者のパーティションのレイアウトに関係なく5以降になります（親拡張パーティションがディスク上の4番目のパーティションである必要はなく、4つのプライマリパーティションすべてが存在する必要もありません）。
デバイス名は通常、異なる Unix ライクなシステム バリアント間で互換性がありません。たとえば、一部のBSDシステムでは、IDE デバイスは/dev/wd0、/dev/wd1などと命名されます。
devfsは、Unix系オペレーティングシステム上でデバイスファイルを表示するために使用される、デバイスファイルシステムの特定の実装です。実装の基本的なメカニズムは、OSによって異なる場合があります。
ハードディスクドライブなどの物理的に実装されたファイルシステム上にこれらの特殊ファイルを維持するのは不便であり、いずれにせよカーネルの支援が必要となるため、物理的に保存されない特殊用途の論理ファイルシステムというアイデアが生まれた。
デバイスが認識可能になったタイミングを定義するのは容易ではありません。devfs のアプローチでは、デバイスドライバが、有効化または無効化するデバイスに関連する devfs エントリの作成と削除を要求します。
デバイスファイルとは、PCのDOS、TOS、OS/2、およびWindowsシステムで使用される予約語であり、特定のポートやデバイスへのアクセスを許可するために使用されます。
MS-DOS はUnix から特殊ファイルの概念を借用したが、デバイスと改名した。[ 1 ]初期の MS-DOS はディレクトリ階層をサポートしていなかったため、デバイスは名前を予約語にすることで通常のファイルと区別された。つまり、特定のファイル名はデバイス用に予約されており、新しいファイルやディレクトリの名前には使用してはならない。[ 13 ] 予約名自体はCP/M のPIPコマンドの「特殊ファイル」処理と互換性があるように選択された。DOS には、ブロック デバイス (ディスク ドライブに使用) と文字デバイス (一般的に COM や PRN デバイスを含むその他のすべてのデバイス) の 2 種類のデバイスがあった。[ 14 ]
DOS はプリンタやポートにアクセスするためにデバイス ファイルを使用します。ほとんどのバージョンの Windows もこのサポートを備えていますが、特定の名前のファイルやフォルダを作成しようとすると、これらの名前を使用できないため混乱が生じる可能性があります。[ 15 ] MS-DOSのバージョン 2.x ではAVAILDEVCONFIG.SYSパラメータが提供されており、これを に設定するとFALSE、これらの特殊な名前は で始まる場合にのみ有効になり\DEV\、通常のファイルをこれらの名前で作成できるようになります。[ 16 ]
Atari TOSの DOS ライクな部分であるGEMDOS は、DOS と同様のデバイス名をサポートしていましたが、DOS とは異なり、通常のファイル名ではなくデバイスとして識別するために末尾に「:」文字が必要でした (DOS ではこれは省略可能です) (したがって、「CON:」は DOS と TOS の両方で機能しますが、「CON」は TOS では通常のファイル名になりますが、DOS ではコンソール デバイスになります)。MiNTとMagiCでは、「U:」ドライブ文字を介してアクセスされる特別な UNIX ライクな統合ファイルシステム ビューによって、デバイス ファイルも「U:\DEV」に配置されました。
シェルリダイレクトとパイプを使用すると、デバイスとの間でデータを送受信できます。たとえば、次のように入力すると、ファイルがc:\data.txtプリンターに送信されます。
TYPE c:\data.txt > PRN PIPE、MAILSLOT、MUPは、その他の標準的なWindowsデバイスです。[ 22 ]
シャープのポケットコンピュータ（PC -E500、PC-E500Sなど）の8ビットオペレーティングシステムは、 BASICインタープリタ、基本的な12ビットFATライクなファイルシステムを実装したDOS 2ライクなファイル制御システム（FCS）、および多数の標準文字およびブロックデバイスドライバ、ならびにSTDO:/SCRN:（ディスプレイ）、STDI:/KYBD:（キーボード）、COM:（シリアルI/O）、 STDL:/PRN:（プリンタ）、CAS:（カセットテープ）、E:/F:/G:（メモリファイル）、S1:/S2:/S3:（メモリカード）、X:/Y:（フロッピー）、SYSTM:（システム）、NIL:（関数）などの特殊ファイルデバイスを実装したBIOSライクな入出力制御システム（IOCS）で構成されています。[ 23 ]
単一オープンデバイスを超えた次のステップは、1人のユーザーが複数のプロセスでデバイスを開くことを許可するが、一度にデバイスを開くことができるのは1人のユーザーのみにすることです。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)は、Linux デバイス ファイルシステムを使用してデバイス ノードを構成可能な方法で管理します。