Почему / 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), и вытекающими из этого преимуществами.

Без сомнения, есть немаловажное преимущество в производительности, если не затягивать дополнительный процесс, но я думаю, что это еще не все: в раннем Unix была метафора «все - файл», которая имеет неочевидное, но элегантное преимущество, если вы посмотрите на это с точки зрения системы, а не с точки зрения сценариев оболочки.

Скажем, у вас есть программа nullкомандной строки и /dev/nullузел устройства. С точки зрения сценариев оболочки, foo | nullпрограмма на самом деле действительно полезна и удобна , foo >/dev/nullнабирает текст чуть дольше и может показаться странной.

Но вот два упражнения:

1. Давайте реализуем программу , nullиспользуя существующие инструменты Unix и /dev/null- легко: 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, мы можем сделать то же самое более окольным путем:

$ 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, являются просто файлами, становится очевидным, что реализация нулевой программы более сложна. Ядро должно обрабатывать записи в файл в любом случае, но в случае / dev / null оно может просто отбросить записи на пол, тогда как с помощью канала оно должно фактически передавать байты другой программе, которая затем должна на самом деле читать их.

Я бы сказал, что есть проблема безопасности, выходящая за рамки исторических парадигм и производительности. Ограничение числа программ с привилегированными учетными данными для выполнения, какими бы простыми они ни были, является фундаментальным принципом безопасности системы. Замена /dev/null, безусловно, потребовалась бы, чтобы иметь такие привилегии из-за использования системными службами. Современные системы безопасности отлично справляются с задачей предотвращения атак, но они не являются надежными. Управляемое ядром устройство, доступ к которому осуществляется в виде файла, гораздо сложнее использовать.

Как и другие уже отмечалось, /dev/null является программа сделана из нескольких строк кода. Просто эти строки кода являются частью ядра.

Чтобы сделать это более понятным, вот реализация Linux: символьное устройство вызывает функции при чтении или записи. Запись на /dev/nullвызовы write_null , а на чтение вызовов read_null , зарегистрированных здесь .

Буквально несколько строк кода: эти функции ничего не делают. Вам понадобится больше строк кода, чем пальцев на руках, только если вы считаете функции, отличные от чтения и записи.

Я надеюсь, что вы также знаете о / dev / chargen / dev / zero и других подобных им, включая / dev / null.

В LINUX / UNIX есть несколько из них - они доступны для того, чтобы люди могли эффективно использовать ФРАГМЕНТЫ ХОРОШОГО ПИСЬМЕННОГО КОДА.

Chargen предназначен для генерации определенного и повторяющегося набора символов - он достаточно быстрый и будет расширять границы последовательных устройств, а также поможет отлаживать последовательные протоколы, которые были написаны, и не пройдут тот или иной тест.

Ноль предназначен для заполнения существующего файла или вывода большого количества нулей

/ dev / null - это просто еще один инструмент с той же идеей.

Все эти инструменты в вашем наборе инструментов означают, что у вас есть шанс на то, чтобы заставить существующую программу сделать что-то уникальное, независимо от их (вашей конкретной потребности) в качестве устройства или замены файла.

Давайте устроим конкурс, чтобы узнать, кто может дать самый захватывающий результат, учитывая только несколько символических устройств в вашей версии LINUX.