私はほとんど興味がありますが、なぜ/ devにネットワークインターフェースがないのですか？
/ devの下にノードとして表されていない他の種類のデバイスはありますか？
承認された回答：
多くのデバイスでは、主な操作は、コンピューターから周辺機器にバイトを送信すること、またはコンピューター上の周辺機器からバイトを受信することです。このようなデバイスはパイプに似ており、キャラクターデバイスとしてうまく機能します。読み取りと書き込みを行わない操作（シリアル回線のフロー制御など）の場合、デバイスはioctlと呼ばれるアドホックコマンドを提供します。
一部のデバイスは通常のファイルに非常によく似ています。それらは有限のバイト数で構成されており、特定の位置に書き込んだ内容は後で同じ位置から読み取ることができます。これらのデバイスはブロックデバイスと呼ばれます。
ネットワークインターフェイスはより複雑です。読み取りと書き込みはバイトではなくパケットです。 readで通常のインターフェースを使用することは可能ですが およびwrite 、それは厄介です：おそらくwriteへの各呼び出し パケットを送信し、readを呼び出すたびに パケットを受信します（そして、バッファが小さすぎてパケットが収まらない場合、パケットは失われます）。
ネットワークインターフェイスは、ioctlのみを提供するデバイスとして存在する可能性があります 。実際、これは一部のUNIXバリアントが行うことですが、Linuxは行いません。このアプローチにはいくつかの利点があります。たとえば、Linuxでは、ネットワークインターフェイスがudevを活用できます。しかし、利点は限られているため、それは行われていません。
ほとんどのネットワーク関連アプリケーションは、個々のネットワークインターフェイスを気にせず、より高いレベルで機能します。たとえば、WebブラウザがTCP接続を確立し、WebサーバーがTCP接続をリッスンしたいとします。この目的のために役立つのは、高レベルのネットワークプロトコル用のデバイスです。例：
{ echo $'GET http://www.google.com/ HTTP/1.0r';
echo $'Host: www.google.comr';
echo $'r' >&0; cat; } <>/dev/tcp/www.google.com/80
実際、kshとbashは、TCPおよびUDPクライアントにそのようなインターフェイスを提供します。ただし、一般に、ネットワークアプリケーションは、ファイルにアクセスするアプリケーションよりも複雑です。ほとんどのデータ交換は、readに類似した呼び出しで行われます。 およびwrite 、接続を確立するには、ファイル名だけでなく、より多くの情報が必要です。たとえば、TCP接続のリッスンには2つのステップがあります。1つはサーバーがリッスンを開始したときに実行され、もう1つはクライアントが接続するたびに実行されます。このような余分な手順は、ファイルAPIにうまく適合しません。これが、ネットワーキングに独自のAPIがある主な理由です。
通常、/devにエントリがない別のクラスのデバイス Linuxでは（ただし、他のいくつかのUNIXバリアントではそうです）、ビデオアダプタがあります。原則として、単純なビデオアダプタはフレームバッファデバイスとして公開できます。フレームバッファデバイスは、各ピクセルの色を表すブロックで構成されたブロックデバイスです。アクセラレーションされたビデオアダプタは、アプリケーションがコマンドを送信するキャラクターデバイスとして表すことができます。ここで、デバイスインターフェイスの欠点は、処理が遅いことです。表示するアプリケーション（実際には、Xサーバー）は、何かを表示するたびにカーネル呼び出しを行う必要があります。代わりに、Xサーバーは高速であるため、ほとんどの場合、ビデオアダプタのメモリに直接書き込みます。