/ dev / nullがファイルなのはなぜですか？その機能が単純なプログラムとして実装されていないのはなぜですか？

Linuxでの特殊ファイルの概念を理解しようとしています。しかし、/dev私の知る限り、Cのいくつかの行でその機能を実装できる場合、特別なファイルを持っているのはばかげているように見えます。

さらに、ほぼ同じ方法で使用することもできます。つまりnull、にリダイレクトする代わりにパイピングし/dev/nullます。ファイルとして持つ特定の理由はありますか？同じファイルにアクセスするプログラムが多すぎるなど、他の多くの問題をファイルにしないのですか？

キャラクター専用デバイスを使用することのパフォーマンス上の利点に加えて、主な利点はモジュール性です。/ dev / nullは、シェルパイプラインだけでなく、ファイルが予想されるほとんどすべてのコンテキストで使用できます。ファイルをコマンドラインパラメーターとして受け入れるプログラムを検討します。

# We don't care about log output.
$ frobify --log-file=/dev/null

# We are not interested in the compiled binary, just seeing if there are errors.
$ gcc foo.c -o /dev/null  || echo "foo.c does not compile!".

# Easy way to force an empty list of exceptions.
$ start_firewall --exception_list=/dev/null

これらはすべて、プログラムをソースまたはシンクとして使用することが非常に面倒な場合です。シェルパイプラインの場合でも、stdoutとstderrは独立してファイルにリダイレクトされる可能性があります。これは、実行可能ファイルをシンクとして実行するのは困難です。

# Suppress errors, but print output.
$ grep foo * 2>/dev/null

公平には、それ自体は通常のファイルではありません。それはキャラクターの特別なデバイスです：

$ file /dev/null
/dev/null: character special (3/2)

ファイルまたはプログラムとしてではなくデバイスとして機能することは、標準の入出力/エラーを含む任意のファイル記述子に添付できるため、入力または出力のリダイレクトがより簡単な操作であることを意味します。

私は、Unix（およびその結果としてLinux）を形作ったビジョン/設計に多くの理由があるのではないかと考えています。

間違いなく、余分なプロセスを回転させないことでパフォーマンスが無視できないほど向上することは間違いありませんが、それ以上のことがあると思います。シェルスクリプトの観点ではなく、システムの観点から。

あなたが持っていると言うnullコマンドラインプログラム、および/dev/nullデバイスノードを。シェルスクリプティングの観点から見ると、foo | nullプログラムは実際には本当に便利で便利であり、入力するfoo >/dev/nullのに少し時間がかかり、奇妙に見えるかもしれません。

ただし、次の2つの演習があります。

1. null既存のUnixツールと/dev/null-easy：を使用してプログラムを実装しましょうcat >/dev/null。できた

2. の/dev/null面で実装できますnullか？

入力を破棄するだけのCコードは些​​細なことですから、そのタスクで仮想ファイルを使用できることがなぜ有用なのかはまだ明らかではないかもしれません。

考えてみてください。ほとんどすべてのプログラミング言語は、ファイル、ファイル記述子、およびファイルパスを操作する必要があります。これらは最初からUnixの「すべてはファイル」パラダイムの一部だったからです。

持っているのがstdoutに書き込むプログラムだけである場合、プログラムは、すべての書き込みを飲み込む仮想ファイルにリダイレクトするか、すべての書き込みを飲み込むプログラムにパイプするかを気にしません。

データの読み取りまたは書き込み（ほとんどのプログラムが行う）のためにファイルパスを取るプログラムがあり、それらのプログラムに「空白入力」または「この出力を破棄する」機能を追加したい場合/dev/nullは、無料で提供されます。

それの優雅さは、関連するすべてのプログラムのコードの複雑さを軽減することに注意してください-システムが実際の「ファイル名」を持つ「ファイル」として提供できる一般的だが特別なユースケースごとに、コードはカスタムコマンドの追加を避けることができます-lineオプションと処理するカスタムコードパス。

優れたソフトウェアエンジニアリングは、問題のいくつかの要素を抽象化するための良いまたは「自然な」メタファーを見つけることに依存することが多く、考えやすくなりますが、柔軟性は維持されるため、基本的に同じ範囲の上位レベルの問題を同じ低レベルの問題の解決策を常に再実装することに時間と精神的なエネルギーを費やす。

「すべてはファイルである」リソースにアクセスするための1つのそのような比喩のようです：あなたが呼び出すopenオブジェクトへの参照（ファイルディスクリプタ）を取得し、階層的名前空間内で指定されたパスの、そしてあなたのことができread、およびwriteファイル記述子に、など。stdin / stdout / stderrは、たまたま事前に開かれたファイル記述子でもあります。パイプは単なるファイルとファイル記述子であり、ファイルリダイレクトを使用すると、これらすべての要素を結び付けることができます。

Unixは、これらの抽象化がどれほどうまく機能したかによって、ある程度成功しました/dev/nullが、全体の一部として最もよく理解されています。

PS「すべてはファイル」のUnixバージョン/dev/nullや、その後に続く多くのシステムに実装されているメタファーのより柔軟で強力な一般化に向けた最初のステップとしての価値があります。

たとえば、Unix /dev/nullでは、カーネル自体に実装する必要があるような特殊なファイルのようなオブジェクトが、ファイル/フォルダー形式で機能を公開するのに十分有用であることが判明し、それ以来、プログラムに方法を提供する複数のシステムが作成されましたそれをするために。

最初の1つは、Unixを作ったのと同じ人々によって作られたPlan 9オペレーティングシステムでした。後に、GNU Hurdはその「翻訳機」で同様のことを行いました。その一方で、Linuxは最終的にFUSEを取得しました（これは現在、他の主流システムにも広がっています）。

パフォーマンス上の理由から、プログラムではなくキャラクターデバイス（通常のファイルのように動作する/dev/null）であると思います。

プログラムである場合、プログラムのロード、開始、スケジューリング、実行、およびその後のプログラムの停止とアンロードが必要になります。あなたが説明している単純なCプログラムは、もちろん多くのリソースを消費しませんが、プロセス管理操作は大規模にコストがかかるため、多数（たとえば数百万）のリダイレクト/パイピングアクションを考慮すると、大きな違いを生むと思いますコンテキストスイッチが含まれます。

別の仮定：プログラムにパイピングするには、受信プログラムによってメモリが割り当てられる必要があります（後で破棄された場合でも）。したがって、ツールにパイプすると、送信プログラムで1回、受信プログラムで2回、メモリ消費が2倍になります。

「すべてがファイル」であり、したがって他のほとんどの回答が基づいているすべての場所での使いやすさは別として、@ user5626466が言及しているようにパフォーマンスの問題もあります。

実際に示すために、次の簡単なプログラムを作成しますnullread.c。

#include <unistd.h>
char buf[1024*1024];
int main() {
        while (read(0, buf, sizeof(buf)) > 0);
}

そしてそれをコンパイルします gcc -O2 -Wall -W nullread.c -o nullread

（注：パイプでlseek（2）を使用することはできません。したがって、パイプを空にする方法は、空になるまでパイプから読み込むことです）。

% time dd if=/dev/zero bs=1M count=5000 |  ./nullread
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 9,33127 s, 562 MB/s
dd if=/dev/zero bs=1M count=5000  0,06s user 5,66s system 61% cpu 9,340 total
./nullread  0,02s user 3,90s system 41% cpu 9,337 total

一方、標準の/dev/nullファイルリダイレクトでは、はるかに優れた速度が得られます（言及されている事実により、コンテキストの切り替えが少なくなり、カーネルはデータをコピーするのではなく無視するなど）。

% time dd if=/dev/zero bs=1M count=5000 > /dev/null
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 1,08947 s, 4,8 GB/s
dd if=/dev/zero bs=1M count=5000 > /dev/null  0,01s user 1,08s system 99% cpu 1,094 total

（これはそこにコメントする必要がありますが、それには大きすぎて完全に読めないでしょう）

あなたの質問は、ファイルの代わりにヌルプログラムを使用することで、おそらく簡単に何かが得られるかのように提起されます。おそらく、「魔法のファイル」という概念を取り除き、代わりに「通常のパイプ」だけを持つことができます。

しかし、パイプもファイルだと考えてください。通常は名前が付けられていないため、ファイル記述子を介してのみ操作できます。

このやや不自然な例を考えてみましょう。

$ echo -e 'foo\nbar\nbaz' | grep foo
foo

Bashのプロセス置換を使用して、より遠回りの方法で同じことを実現できます。

$ grep foo <(echo -e 'foo\nbar\nbaz')
foo

grepfor echoを交換すると、カバーの下に表示されます。

$ echo foo <(echo -e 'foo\nbar\nbaz')
foo /dev/fd/63

<(...)構築物を、ただそれだけで名前を付けることを起こる、ファイル名に置き換え、とgrepは、それが任意の古いファイルを開くことだと思っています/dev/fd/63。これ/dev/fdは、アクセスするファイルが所有するすべてのファイル記述子の名前付きパイプを作成する魔法のディレクトリです。

通常のファイルのように、すべてにmkfifo現れる名前付きパイプを作成することで、魔法を減らすことができlsます。

$ mkfifo foofifo
$ ls -l foofifo 
prw-rw-r-- 1 indigo indigo 0 Apr 19 22:01 foofifo
$ grep foo foofifo

他の場所：

$ echo -e 'foo\nbar\nbaz' > foofifo

そして、見よ、grepは出力しますfoo。

パイプと通常のファイル、および/ dev / nullなどの特別なファイルはすべて単なるファイルであることに気づいたら、nullプログラムの実装はより複雑になります。カーネルはどちらの方法でもファイルへの書き込みを処理する必要がありますが、/ dev / nullの場合は書き込みを床に落とすことができますが、パイプでは実際にバイトを別のプログラムに転送する必要があります。実際に読んでください。

私は、歴史的なパラダイムとパフォーマンスを超えたセキュリティ問題があると主張します。特権実行資格情報を使用してプログラムの数を制限することは、どんなに単純であっても、システムセキュリティの基本原則です。/dev/nullシステムサービスで使用するため、このような特権を持つためには、必ず交換が必要になります。最新のセキュリティフレームワークは、悪用を防止する優れた機能を果たしますが、絶対確実ではありません。ファイルとしてアクセスされるカーネル駆動デバイスは、悪用するのがはるかに困難です。

他の人が既に指摘したように、/dev/null あるコードの行の少数からなるプログラム。これらのコード行がカーネルの一部であるというだけです。

より明確にするために、Linuxの実装を次に示します。キャラクタデバイスは、読み取りまたは書き込み時に関数を呼び出します。ここで登録されたread_nullの呼び出しを読み取りながら、write_nullの/dev/null呼び出しへの書き込み。

文字通り数行のコード：これらの関数は何もしません。読み取りと書き込み以外の機能をカウントする場合にのみ、手の指よりも多くのコード行が必要になります。

/ dev / chargen / dev / zeroおよび/ dev / nullを含むそれらのような他のものも知っていることを願っています。

LINUX / UNIXにはこれらのいくつかがあります-人々がよく書かれたコードフラグをうまく利用できるように利用可能になっています。

Chargenは、特定の繰り返しパターンの文字を生成するように設計されています-非常に高速で、シリアルデバイスの限界を押し上げ、テストなどで作成および失敗したシリアルプロトコルのデバッグに役立ちます。

ゼロは、既存のファイルを作成するか、ゼロを大量に出力するように設計されています

/ dev / nullは、同じ考えを念頭に置いた別のツールです。

ツールキット内のこれらのツールはすべて、既存のプログラムがデバイスまたはファイルの代替としての（特定のニーズ）に関係なく、独自の何かをするチャンスが半分あることを意味します。

コンテストを設定して、ご使用のLINUXのバージョンの少数のキャラクターデバイスのみを対象に、誰が最もエキサイティングな結果を出すことができるかを確認しましょう。