一部のファイルがダミーファイルの場合、open()関数がまだそのファイルにアクセスできるのはなぜですか?

一部のファイルがダミーファイルの場合、open()関数がまだそのファイルにアクセスできるのはなぜですか?

私たちは多くのファイルが偽、つまり実際のファイルではないことを知っています。

前任者:

/sys/xxx
/proc/xxx
/dev/xxxx

私が理解したように、open()x86 ASMコードが呼び出され、ASMコードはディスクにアクセスするためのハードウェア割り込みを実行します。

問題は、open()最終的にディスクにアクセスできるかどうかです。ダミーファイルにアクセスするにはどうすればよいですかopen()

答え1

open()説明したように、システムコールは機能しません。代わりにカーネルにファイルを開くように要求します。カーネルは、ファイルがどのファイルシステムにあり、どのデバイスに関連付けられているかを知っています。これは物理ハードドライブ、メモリブロックなどとすることができる。関連付けられたデバイスが単純なメモリブロックの場合、ディスクアクセスは実行されません。

答え2

〜のようにキツネ彼ら回答、カーネルはopen()システムコールを処理し、ファイルシステムは独自の方法でファイル操作を実装します。一方、ファイルシステムはそのバージョンのシステムコールを実装し、これがカーネルが使用する必要があることです。

例えば、ディレクトリを開くためのext4呼び出しまたはprocfsのファイル操作(特にどこにも言及されていない.open管路名前付きパイプと名前なしパイプを処理します。しかし、一般的なアイデアは、open()システムコールが必ずしもアセンブラである必要はなく、特定のアーキテクチャに固有であることも保証されていないことです。

そして引用する回答ユーザー別ウォーレンヤングこの質問が出る前に誰がこの事実に気づいたのでしょうか。

単一ファイルの mkdir() は存在しません。 Linuxはそれぞれ独自に「mkdir」操作を実装するさまざまなファイルシステムをサポートしています。カーネルが単一のシステムコールの後にすべてを隠すことを可能にする抽象化レイヤーをVFSと呼びます。したがって、vfs_mkdir() を使用して fs/namei.c の調査を開始できます。低レベルのファイルシステム修正コードの実際の実装は他の場所にあります。たとえば、ext4実装はext4_mkdir()と呼ばれ、fs / ext4 / namei.cで定義されています。

open()なぜそうかとすれば、これもそうだからだ。Unixデザイン哲学:すべてはファイルです。 APIを使用している場合は、すべてのファイルシステムに対してホイールを再発明するのではなく、一貫したインターフェースを扱いたいと思うでしょう(カーネル開発者でなければ監査と尊敬を表します)。

関連情報