したがって、ここには基本的に 2 つの異なるタイプがあります:
<オール>/proc と /sys sshfs のような FUSE カスタム ファイルシステムと同様に、ここに例があります。 または ifuse .実際には、ある意味で「カスタム」なセマンティクスを持つファイルシステムを参照しているだけなので、これらにははるかに多様性があります。したがって、/proc の下のファイルから読み取ると、 、通常のファイルシステムのように、以前に別の何かによって保存された特定のデータに実際にアクセスしているわけではありません。基本的にカーネル呼び出しを行っており、オンザフライで生成された情報を要求しています。このコードは、read を実装するどこかの関数にすぎないため、好きなことを何でも実行できます。 セマンティクス。したがって、 /proc 未満のファイルの奇妙な動作があります たとえば、実際にはシンボリック リンクではないのにシンボリック リンクのふりをするなどです。
キーは /dev です 実際には、通常、最初の種類の 1 つです。最近のディストリビューションでは /dev を持つのが普通です tmpfs のようなものですが、古いシステムでは、特別な属性を持たない、ディスク上の単純なディレクトリにするのが普通でした。キーは、/dev の下のファイルです。 FIFOまたはUnixソケットに似たタイプの特殊ファイルであるデバイスノードです。デバイスノードにはメジャー番号とマイナー番号があり、FIFO の読み取りまたは書き込みがカーネルを呼び出して出力をパイプにバッファリングするのと同じように、それらの読み取りまたは書き込みはカーネルドライバーへの呼び出しを行います。このドライバーは、やりたいことは何でもできますが、通常は何らかの方法でハードウェアに触れます。ハードディスクにアクセスしたり、スピーカーでサウンドを再生したりします。
元の質問に答えるには:
<オール>
「ファイルが存在する」かどうかに関連する 2 つの質問があります。これらは、デバイス ノード ファイルが文字通り存在するかどうか、およびそれをサポートするカーネル コードが意味を持つかどうかです。前者は、通常のファイルシステムと同様に解決されます。最新のシステムは udev を使用します または、ハードウェア イベントを監視し、/dev の下のデバイス ノードを自動的に作成および破棄するようなもの によると。しかし、古いシステムや軽量のカスタム ビルドでは、事前に作成されたディスク上に文字通りすべてのデバイス ノードを配置できます。一方、これらのファイルを読み取るときは、メジャー デバイス番号とマイナー デバイス番号によって決定されるカーネル コードを呼び出しています。これらが適切でない場合 (たとえば、存在しないブロック デバイスを読み込もうとしている場合)、何らかの I/O エラーが発生します。
どのデバイス ファイルに対してどのカーネル コードを呼び出すかを決定する方法はさまざまです。 /proc のような仮想ファイルシステムの場合 、独自の read を実装しています と write 機能;カーネルは、それがどのマウント ポイントにあるかに応じてそのコードを呼び出すだけで、残りはファイル システムの実装が処理します。デバイス ファイルの場合、メジャー デバイス番号とマイナー デバイス番号に基づいてディスパッチされます。
/dev/sda1 のファイル一覧です。 ほぼ最新の Arch Linux サーバーで:
% ls -li /dev/sda1
1294 brw-rw---- 1 root disk 8, 1 Nov 9 13:26 /dev/sda1
/dev/ のディレクトリ エントリ sda の場合 i ノード番号は 1294 です。これはディスク上の実際のファイルです。
通常、ファイル サイズが表示される場所を確認します。代わりに「8, 1」が表示されます。これはメジャーおよびマイナー デバイス番号です。また、ファイル許可の 'b' にも注意してください。
ファイル /usr/include/ext2fs/ext2_fs.h この (フラグメント) C 構造体が含まれています:
/*
* Structure of an inode on the disk
*/
struct ext2_inode {
__u16 i_mode; /* File mode */
この構造体は、ファイルの inode のディスク上の構造を示しています。この構造体には興味深いものがたくさんあります。よく見てください。
i_mode struct ext2_inode の要素 には 16 ビットがあり、ユーザー/グループ/その他、読み取り/書き込み/実行のアクセス許可に 9 つだけを使用し、setuid、setgid、およびスティッキーに別の 3 つを使用します。 「プレーン ファイル」、「リンク」、「ディレクトリ」、「名前付きパイプ」、「Unix ファミリ ソケット」、「ブロック デバイス」などのタイプを区別するための 4 ビットがあります。
Linux カーネルは、通常のディレクトリ ルックアップ アルゴリズムに従い、i_mode のパーミッションとフラグに基づいて決定を下すことができます。 エレメント。 'b' (ブロックデバイスファイル) の場合、メジャーデバイス番号とマイナーデバイス番号を見つけることができ、伝統的にメジャーデバイス番号を使用して、ディスクを処理するカーネル関数 (デバイスドライバー) へのポインターを検索します。マイナー デバイス番号は通常、SCSI バス デバイス番号や EIDE デバイス番号などとして使用されます。
/proc/cpuinfo のようなファイルの処理方法に関するその他の決定事項 ファイルシステムのタイプに基づいて作成されます。次の場合:
% mount | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
/proc であることがわかります 「proc」のファイルシステムタイプを持っています。 /proc のファイルからの読み取り ReiserFS または DOS ファイル システムでファイルを開くと、カーネルがさまざまな関数を使用してファイルを検索し、ファイルのデータを検索するのと同じように、ファイル システムの種類に基づいてカーネルが別の処理を実行します。
結局のところ、それらはすべて Unix 用のファイルです。これが抽象化の美しさです。
ファイルがカーネルによって処理される方法は、今では別の話です。
/proc と最近では /dev と /run (別名 /var/run) は RAM 内の仮想ファイルシステムです。 /proc は、カーネル変数と構造体へのインターフェイス/ウィンドウです。
The Linux Kernel http://tldp.org/LDP/tlk/tlk.html と Linux Device Drivers, Third Edition https://lwn.net/Kernel/LDD3/ を読むことをお勧めします。
また、FreeBSD オペレーティング システムの設計と実装も楽しみました http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0321968972/ref=sr_1_1
あなたの質問に関連するページを見てください。
http://www.tldp.org/LDP/tlk/dd/drivers.html