Dlaczego / dev / null jest plikiem? Dlaczego jego funkcja nie jest zaimplementowana jako prosty program?

Próbuję zrozumieć pojęcie specjalnych plików w systemie Linux. Jednak posiadanie specjalnego pliku /devwydaje się głupie, gdy jego funkcja może być zaimplementowana przez kilka wierszy w C, o ile mi wiadomo.

Co więcej, możesz go używać w prawie ten sam sposób, tj. Wpakowywanie do nullzamiast przekierowywania do /dev/null. Czy jest jakiś konkretny powód, aby mieć go jako plik? Czy utworzenie pliku nie powoduje wielu innych problemów, takich jak zbyt wiele programów uzyskujących dostęp do tego samego pliku?

Oprócz korzyści związanych z wydajnością korzystania ze specjalnego urządzenia, podstawową korzyścią jest modułowość . / dev / null może być używany w prawie każdym kontekście, w którym oczekiwany jest plik, nie tylko w potokach powłoki. Rozważ programy, które akceptują pliki jako parametry wiersza polecenia.

# 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

Są to wszystkie przypadki, w których użycie programu jako źródła lub ujścia byłoby wyjątkowo kłopotliwe. Nawet w przypadku potoku powłoki stdout i stderr mogą być przekierowywane do plików niezależnie, co jest trudne do zrobienia w plikach wykonywalnych takich jak sinking:

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

Szczerze mówiąc, nie jest to zwykły plik jako taki ; to specjalne urządzenie postaci :

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

Działa jako urządzenie, a nie jako plik lub program, oznacza, że ​​łatwiej jest przekierować dane wejściowe lub wyjściowe, ponieważ można je podłączyć do dowolnego deskryptora pliku, w tym standardowego wejścia / wyjścia / błędu.

Podejrzewam, dlaczego ma to wiele wspólnego z wizją / projektowaniem, które ukształtowało Uniksa (a co za tym idzie Linuksa) oraz wynikające z niego korzyści.

Nie ma wątpliwości, że nie ma dodatkowej korzyści w zakresie wydajności, jeśli nie rozpędza się dodatkowego procesu, ale myślę, że jest coś więcej: wczesny Unix miał metaforę „wszystko jest plikiem”, co ma nieoczywistą, ale elegancką zaletę, jeśli spojrzysz na z perspektywy systemowej, a nie z perspektywy skryptów powłoki.

Załóżmy, że masz nullprogram wiersza polecenia i /dev/nullwęzeł urządzenia. Z punktu widzenia skryptowania powłoki foo | nullprogram jest naprawdę przydatny i wygodny , a foo >/dev/nullpisanie zajmuje trochę więcej czasu i może wydawać się dziwny.

Ale oto dwa ćwiczenia:

1. Spójrzmy prawdzie w realizacji programu nullprzy użyciu istniejących narzędzi Unix i /dev/null- łatwa: cat >/dev/null. Gotowy.

2. Czy możesz wdrożyć /dev/nullpod względem null?

Masz całkowitą rację, że kod C, aby po prostu odrzucić dane wejściowe, jest trywialny, więc może nie być jeszcze oczywiste, dlaczego warto mieć plik wirtualny dostępny dla zadania.

Zastanów się: prawie każdy język programowania musi już pracować z plikami, deskryptorami plików i ścieżkami plików, ponieważ były one od początku częścią uniksowego paradygmatu „wszystko jest plikiem”.

Jeśli wszystko, co masz, to programy, które piszą na standardowe wyjście, cóż, program nie dba o to, czy przekierujesz je do wirtualnego pliku, który połyka wszystkie zapisy, lub potoku do programu, który połyka wszystkie zapisy.

Teraz, jeśli masz programy, które pobierają ścieżki plików zarówno do odczytu, jak i zapisu danych (co robi większość programów) - i chcesz dodać do tych programów funkcję „pustego wejścia” lub „odrzuć to wyjście” - cóż, /dev/nulljest to bezpłatne.

Zauważ, że jego elegancją jest to, że zmniejsza złożoność kodu wszystkich zaangażowanych programów - dla każdego wspólnego, ale specjalnego przypadku użycia, który twój system może zapewnić jako „plik” z rzeczywistą „nazwą pliku”, twój kod może uniknąć dodania niestandardowego polecenia -line opcje i niestandardowe ścieżki kodu do obsługi.

Dobra inżynieria oprogramowania często zależy od znalezienia dobrych lub „naturalnych” metafor dla wyodrębnienia jakiegoś elementu problemu w sposób, który staje się łatwiejszy do myślenia, ale pozostaje elastyczny , dzięki czemu można rozwiązać zasadniczo ten sam zakres problemów wyższego poziomu bez konieczności spędzaj czas i energię psychiczną na ciągłym wdrażaniu rozwiązań tych samych problemów niższego poziomu.

„Wszystko jest plikiem” wydaje się być jednym z takich metaforą dostępu do zasobów: Dzwonisz openz danej ścieżki w obszarze nazw heirarchical, coraz odniesienia (deskryptor) do obiektu, a można readi writeitp na deskryptorów plików. Twoje stdin / stdout / stderr to także deskryptory plików, które właśnie zostały dla Ciebie wstępnie otwarte. Twoje potoki to tylko pliki i deskryptory plików, a przekierowanie plików pozwala skleić wszystkie te elementy razem.

Uniksowi udało się tak samo, jak częściowo, ze względu na to, jak dobrze te abstrakcje działały razem, i /dev/nullnajlepiej jest to rozumieć jako część tej całości.

PS Warto spojrzeć na uniksową wersję „wszystko jest plikiem” i rzeczy takie /dev/nulljak pierwsze kroki w kierunku bardziej elastycznego i potężnego uogólnienia metafory zaimplementowanej w wielu późniejszych systemach.

Na przykład w Uniksie specjalne obiekty podobne /dev/nulldo plików, takie jak musiały zostać zaimplementowane w samym jądrze, ale okazuje się, że wystarczające jest udostępnienie funkcjonalności w postaci pliku / folderu, która od tego czasu stworzyła wiele systemów, które zapewniają sposób dla programów aby to zrobić.

Jednym z pierwszych był system operacyjny Plan 9, stworzony przez tych samych ludzi, którzy stworzyli Uniksa. Później GNU Hurd zrobił coś podobnego ze swoimi „tłumaczami”. Tymczasem Linux skończył się FUSE (który również rozprzestrzenił się na inne systemy głównego nurtu).

Myślę, że /dev/nullto urządzenie znakowe (które zachowuje się jak zwykły plik) zamiast programu ze względu na wydajność .

Jeśli byłby to program, wymagałby ładowania, uruchamiania, planowania, uruchamiania, a następnie zatrzymywania i rozładowywania programu. Prosty program C, który opisujesz, nie zużyłby wiele zasobów, ale myślę, że robi to znaczącą różnicę, biorąc pod uwagę dużą liczbę (powiedzmy miliony) działań przekierowujących / potokowych, ponieważ operacje zarządzania procesami są kosztowne na dużą skalę, ponieważ obejmują przełączniki kontekstu.

Kolejne założenie: Pipingowanie do programu wymaga przydzielenia pamięci przez program odbierający (nawet jeśli jest on następnie usuwany bezpośrednio). Jeśli więc podłączasz się do narzędzia, masz podwójne zużycie pamięci, raz w programie wysyłającym i ponownie w programie odbierającym.

Oprócz „wszystko jest plikiem”, a zatem łatwości użycia wszędzie tam, gdzie opiera się większość innych odpowiedzi, istnieje również problem z wydajnością, jak wspomniano w @ user5626466.

Aby pokazać w praktyce, stworzymy prosty program o nazwie nullread.c:

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

i skompiluj to z gcc -O2 -Wall -W nullread.c -o nullread

(Uwaga: nie możemy używać lseek (2) na rurach, więc jedynym sposobem na opróżnienie rury jest czytanie z niej, dopóki nie będzie pusta).

% 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

podczas gdy ze standardowym /dev/nullprzekierowaniem plików uzyskujemy znacznie lepszą prędkość (ze względu na wspomniane fakty: mniej przełączania kontekstu, jądro po prostu ignoruje dane zamiast kopiować itp.):

% 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

(powinien to być komentarz, ale jest na to za duży i byłby całkowicie nieczytelny)

Twoje pytanie jest postawione tak, jakby coś można było uzyskać, być może w prostocie, za pomocą programu zerowego zamiast pliku. Być może możemy pozbyć się pojęcia „magicznych plików” i zamiast tego mieć po prostu „zwykłe fajki”.

Ale zastanów się, potok jest również plikiem . Zwykle nie są nazwane, więc można nimi manipulować tylko za pomocą deskryptorów plików.

Rozważmy ten nieco wymyślony przykład:

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

Korzystając z zastępowania procesów przez Basha, możemy osiągnąć to samo w bardziej okrągły sposób:

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

Wymień grepna echoi możemy zobaczyć pod okładkami:

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

<(...)Konstrukt jest po prostu wymienić z nazwy pliku, grep i uważa, że to otwarcie byle plik, to właśnie dzieje się w nazwie /dev/fd/63. Oto /dev/fdmagiczny katalog, który tworzy nazwane potoki dla każdego deskryptora pliku posiadanego przez plik uzyskujący do niego dostęp.

Możemy sprawić, by mniej magii mkfifobyło stworzenie nazwanego potoku, który pojawiłby się lsi wszystko, tak jak zwykły plik:

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

Gdzie indziej:

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

a oto grep wyświetli foo.

Myślę, że kiedy zdasz sobie sprawę, że potoki i zwykłe pliki oraz specjalne pliki, takie jak / dev / null, są tylko plikami, to oczywiste jest, że implementacja programu zerowego jest bardziej złożona. Jądro musi obsługiwać zapisy do pliku w dowolny sposób, ale w przypadku / dev / null może po prostu upuścić zapisy na podłogę, podczas gdy za pomocą potoku musi faktycznie przenieść bajty do innego programu, który następnie musi faktycznie je czytam.

Twierdziłbym, że istnieje problem bezpieczeństwa wykraczający poza historyczne paradygmaty i wydajność. Ograniczenie liczby programów posiadających uprzywilejowane poświadczenia wykonania, bez względu na to, jak proste, jest podstawową zasadą bezpieczeństwa systemu. Z /dev/nullpewnością konieczna byłaby wymiana , aby mieć takie uprawnienia ze względu na korzystanie z usług systemowych. Nowoczesne ramy bezpieczeństwa wykonują doskonałą pracę, zapobiegając exploitom, ale nie są niezawodne. Urządzenie napędzane przez jądro, do którego dostęp uzyskuje się jako plik, jest znacznie trudniejsze do wykorzystania.

Jak już zauważyli inni, /dev/null jest to program złożony z kilku wierszy kodu. Po prostu te wiersze kodu są częścią jądra.

Aby to wyjaśnić, oto implementacja systemu Linux: urządzenie znakowe wywołuje funkcje podczas odczytu lub zapisu. Zapisywanie do /dev/nullpołączeń write_null , podczas odczytywania połączeń read_null , zarejestrowanych tutaj .

Dosłownie garstka wierszy kodu: te funkcje nic nie robią. Potrzebujesz więcej linii kodu niż palców na dłoniach, tylko jeśli policzysz funkcje inne niż czytanie i pisanie.

Mam nadzieję, że znasz również / dev / chargeen / dev / zero i inni je lubią, w tym / dev / null.

LINUX / UNIX ma kilka z nich - udostępnionych, aby ludzie mogli dobrze wykorzystać WELL PISEMNE KOD Fragme.

Chargen ma na celu generowanie określonego i powtarzającego się wzoru znaków - jest dość szybki i przesuwa granice urządzeń szeregowych i pomaga debugować protokoły szeregowe, które zostały napisane i nieudane w jakimś teście lub innym.

Zero ma za zadanie wypełnić istniejący plik lub wyprowadzić wiele zer

/ dev / null to kolejne narzędzie z myślą o tym samym pomyśle.

Wszystkie te narzędzia w zestawie narzędzi oznaczają, że masz pół szansy, aby istniejący program zrobił coś wyjątkowego bez względu na ich (Twoją konkretną potrzebę) rolę urządzeń lub zamienników plików

Pozwala zorganizować konkurs, aby zobaczyć, kto może uzyskać najbardziej ekscytujący wynik, biorąc pod uwagę tylko kilka urządzeń postaci w twojej wersji LINUX.