为什么/ dev / null是文件？为什么不将其功能实现为简单程序？

我试图理解Linux上特殊文件的概念。但是，据/dev我所知，当可以用C中的几行代码实现其功能时，在其中包含特殊文件似乎很愚蠢。

此外，您可以以几乎相同的方式使用它，即，通过管道连接到，null而不是重定向到/dev/null。将其作为文件有特定的原因吗？使其不成为文件会导致许多其他问题，例如太多程序正在访问同一文件吗？

除了使用特殊字符设备带来的性能优势外，主要优势还在于模块化。/ dev / null几乎可以在任何需要文件的上下文中使用，而不仅仅是在shell管道中。考虑接受文件作为命令行参数的程序。

# 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

在所有这些情况下，使用程序作为源或接收器都非常麻烦。即使在shell流水线情况下，stdout和stderr也可以独立地重定向到文件，这对于将可执行文件作为接收器是很难做到的：

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

公平地说，它本身不是常规文件；这是一个特殊字符设备：

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

它充当设备而不是文件或程序的功能意味着将输入重定向到它或从它输出是一个更简单的操作，因为它可以附加到任何文件描述符，包括标准输入/输出/错误。

我怀疑为什么与Unix（进而是Linux）的构想/设计有很多关系，以及它的优势。

毫无疑问，不进行额外的处理会带来不可忽略的性能优势，但我认为还有更多的好处：早期的Unix有一个“一切都是文件”的比喻，如果您看一下，它具有非显而易见但优雅的优势。从系统角度来看，而不是从Shell脚本角度来看。

假设您拥有null命令行程序和/dev/null设备节点。从shell脚本的角度来看，该foo | null程序实际上是真正有用且方便的，而且foo >/dev/null键入时间稍长，而且看起来很奇怪。

但是这里有两个练习：

1. 让我们null使用现有的Unix工具/dev/null-easy：实现该程序cat >/dev/null。做完了

2. 您可以/dev/null按照实施null吗？

完全正确的做法是，仅丢弃输入的C代码是微不足道的，因此，尚不清楚为什么为该任务提供虚拟文件很有用。

考虑一下：几乎每种编程语言都已经需要使用文件，文件描述符和文件路径，因为它们从一开始就是Unix“一切都是文件”范例的一部分。

如果您所拥有的只是写到stdout的程序，那么该程序将不在乎您是否将它们重定向到可吞噬所有写操作的虚拟文件，或将管道重定向到可吞噬所有写操作的程序。

现在，如果您的程序采用了用于读取或写入数据的文件路径（大多数程序都这样做），并且您想向这些程序添加“空白输入”或“丢弃此输出”功能-那么，/dev/null它是免费提供的。

请注意，它的优雅之处在于降低了所有相关程序的代码复杂性-对于系统可以以带有实际“文件名”的“文件”形式提供的每个常见但特殊的用例，您的代码都可以避免添加自定义命令行选项和要处理的自定义代码路径。

好的软件工程通常依赖于找到好的或“自然的”隐喻来抽象问题的某些元素，从而使问题变得更容易思考，但仍保持灵活性，因此您可以解决基本上相同范围的高级问题，而不必花时间和精力在不断地为相同的较低级别的问题实施解决方案上。

“一切都是文件”似乎就是访问资源的这种比喻：您open在分层命名空间中调用给定路径，获取对对象的引用（文件描述符），并且可以在文件描述符上使用read和write，等等。您的stdin / stdout / stderr也是刚为您打开的文件描述符。您的管道只是文件和文件描述符，文件重定向使您可以将所有这些片段粘合在一起。

Unix之所以取得成功，部分原因在于这些抽象如何协同工作，并且/dev/null最好是整体上的一部分。

PS值得一看的是Unix版本的“一切都是文件”以及类似/dev/null的东西，这是对隐喻进行更灵活，更强大的概括的第一步，该隐喻已在随后的许多系统中实现。

例如，在Unix中，类似文件的特殊对象/dev/null必须在内核本身中实现，但是事实证明，以文件/文件夹形式公开功能是很有用的，此后便形成了多个为程序提供方法的系统要做到这一点。

第一个是Plan 9操作系统，它是由与Unix相同的一些人开发的。后来，GNU Hurd对其“翻译器”进行了类似的操作。同时，Linux最终获得了FUSE（目前也已经传播到其他主流系统）。

我认为出于性能原因，它/dev/null是字符设备（其行为类似于普通文件）而不是程序。

如果是程序，则需要加载，启动，调度，运行，然后再停止和卸载程序。您所描述的简单C程序当然不会消耗大量资源，但是我认为当考虑大量（例如数百万）重定向/管道操作时，它会产生重大影响，因为过程管理操作的成本很高，因为它们涉及上下文切换。

另一个假设：插入程序需要由接收程序分配内存（即使此后直接丢弃）。因此，如果通过管道传输该工具，则会消耗双倍的内存，一次在发送程序上，另一次在接收程序上。

除了“一切都是文件”，并因此在大多数其他答案所基于的地方都易于使用之外，还存在@ 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的流程替换，我们可以通过一种更round回的方式来完成同一件事：

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

替换grep为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的实现：字符设备在读取或写入时调用函数。写入/dev/null调用write_null，而读取调用read_null，在此注册。

从字面上看是少数几行代码：这些函数什么都不做。仅当您计数读写以外的功能时，您才需要多于几行代码。

我希望您也了解/ dev / chargen / dev / zero以及其他类似的东西，包括/ dev / null。

LINUX / UNIX中有一些-已提供，因此人们可以充分利用WELL书面代码标记。

Chargen旨在生成特定且重复的字符模式-速度非常快，并且将突破串行设备的极限，并且将有助于调试已编写的，在某些测试或其他测试中失败的串行协议。

零旨在填充现有文件或输出大量零

/ dev / null只是另一个具有相同想法的工具。

工具箱中的所有这些工具意味着您有一半的机会让现有程序执行独特的操作，而无需考虑它们（您的特定需求）作为设备或文件替换的可能性。

让我们设置一个竞赛，看看在您的LINUX版本中，只有很少的字符设备，谁才能产生最令人兴奋的结果。