Чому файл / dev / null - файл? Чому його функція не реалізована як проста програма?

Я намагаюся зрозуміти поняття спеціальних файлів в Linux. Однак, маючи спеціальний файл у, /devздається, нерозумно, коли його функцію можна було реалізовувати за допомогою декількох рядків у С, наскільки мені відомо.

Крім того, ви можете використовувати його майже однаково, тобто підключення, 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), та переваг, що випливають з цього.

Без сумніву, є несуттєва користь від продуктивності, щоб не розгортати зайвий процес, але я думаю, що в цьому є і більше: Early 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

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

$ 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

і ось, греп виведе foo.

Я думаю , як тільки ви розумієте , трубу і звичайні файли і спеціальні файли , такі як / DEV / нуль все тільки файли, це очевидно , впровадження нульової програми є більш складним. Ядро повинно в будь-якому випадку керувати записом у файл, але у випадку / 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.