Warum ist / dev / null eine Datei? Warum ist seine Funktion nicht als einfaches Programm implementiert?

Ich versuche das Konzept spezieller Dateien unter Linux zu verstehen. Ein spezielles File in zu haben, /deverscheint mir jedoch albern, wenn die Funktion meines Wissens durch ein paar Zeilen in C implementiert werden könnte.

Darüber hinaus können Sie es auf die gleiche Art und Weise verwenden, z. B. nullumleiten, anstatt umzuleiten /dev/null. Gibt es einen bestimmten Grund dafür, es als Datei zu haben? Verursacht das Erstellen einer Datei nicht viele andere Probleme, z. B. zu viele Programme, die auf dieselbe Datei zugreifen?

Neben den Leistungsvorteilen der Verwendung eines charakterspezifischen Geräts liegt der Hauptvorteil in der Modularität . / dev / null kann in fast jedem Kontext verwendet werden, in dem eine Datei erwartet wird, nicht nur in Shell-Pipelines. Betrachten Sie Programme, die Dateien als Befehlszeilenparameter akzeptieren.

# 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

Dies sind alle Fälle, in denen die Verwendung eines Programms als Quelle oder Senke äußerst umständlich wäre. Sogar im Fall einer Shell-Pipeline können stdout und stderr unabhängig voneinander in Dateien umgeleitet werden, was mit ausführbaren Dateien als Senken schwierig zu tun ist:

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

Fairerweise handelt es sich nicht um eine reguläre Datei an sich. Es ist ein spezielles Zeichengerät :

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

Da es als Gerät und nicht als Datei oder Programm fungiert, ist es einfacher, Eingaben in das Gerät oder Ausgaben daraus umzuleiten, da es an jeden Dateideskriptor angehängt werden kann, einschließlich Standardeingabe / -ausgabe / -fehler.

Ich vermute, dass das Warum viel mit der Vision / dem Design zu tun hat, das Unix (und folglich Linux) geprägt hat, und den Vorteilen, die sich daraus ergeben.

Kein Zweifel, es ist ein nicht zu vernachlässigender Leistungsvorteil, keinen zusätzlichen Prozess zu starten, aber ich denke, es steckt noch mehr dahinter: Early Unix hatte eine Metapher "Alles ist eine Datei", die einen nicht offensichtlichen, aber eleganten Vorteil hat, wenn man sich das ansieht es aus einer Systemperspektive und nicht aus einer Shell-Skriptperspektive.

Angenommen, Sie haben Ihr nullBefehlszeilenprogramm und /dev/nullden Geräteknoten. Von einer Shell-Scripting - Perspektive, das foo | nullist Programm eigentlich wirklich nützlich und bequem , und foo >/dev/nullnimmt ein kleines bisschen länger kann zu geben und seltsam erscheinen.

Aber hier sind zwei Übungen:

1. Lassen Sie uns die Umsetzung des Programms in nulleinem der vorhandenen Unix - Tools und /dev/null- einfach: cat >/dev/null. Getan.

2. Können Sie /dev/nullin Bezug auf implementieren null?

Sie haben absolut Recht, dass der C-Code zum Verwerfen von Eingaben trivial ist. Daher ist es möglicherweise noch nicht klar, warum es nützlich ist, eine virtuelle Datei für die Aufgabe zur Verfügung zu haben.

Bedenken Sie: Fast jede Programmiersprache muss bereits mit Dateien, Dateideskriptoren und Dateipfaden arbeiten, da diese von Anfang an Teil des Unix-Paradigmas "Alles ist eine Datei" waren.

Wenn Sie nur Programme haben, die nach stdout schreiben, ist es dem Programm egal, ob Sie sie in eine virtuelle Datei umleiten, die alle Schreibvorgänge schluckt, oder eine Pipe in ein Programm, das alle Schreibvorgänge schluckt.

Wenn Sie nun Programme haben, die Dateipfade zum Lesen oder Schreiben von Daten verwenden (was die meisten Programme tun) - und diesen Programmen die Funktion "Leereingabe" oder "Ausgabe verwerfen" hinzufügen möchten -, ist dies /dev/nullkostenlos.

Beachten Sie, dass die Eleganz darin besteht, dass die Codekomplexität aller beteiligten Programme verringert wird. Für jeden allgemeinen, aber besonderen Verwendungszweck, den Ihr System als "Datei" mit einem tatsächlichen "Dateinamen" bereitstellen kann, kann Ihr Code das Hinzufügen eines benutzerdefinierten Befehls vermeiden -Line-Optionen und benutzerdefinierte Codepfade zu behandeln.

Gutes Software-Engineering hängt oft davon ab, gute oder "natürliche" Metaphern zu finden, um ein Element eines Problems auf eine Weise zu abstrahieren, die leichter zu überlegen ist, aber dennoch flexibel bleibt , sodass Sie im Grunde die gleichen Probleme auf höherer Ebene lösen können, ohne dass dies erforderlich ist verbringen Sie die Zeit und die geistige Energie damit, Lösungen für dieselben Probleme auf niedrigerer Ebene ständig neu zu implementieren.

"Alles ist eine Datei" scheint eine solche Metapher für den Zugriff auf Ressourcen zu sein: Sie rufen openeinen bestimmten Pfad in einem hierarchischen Namespace auf, erhalten einen Verweis (Dateideskriptor) auf das Objekt, und Sie können readund writeusw. auf die Dateideskriptoren. Ihre stdin / stdout / stderr sind auch Dateideskriptoren, die gerade für Sie vorab geöffnet wurden. Ihre Pipes sind nur Dateien und Dateideskriptoren, und mit der Dateiumleitung können Sie all diese Teile zusammenfügen.

Unix war ebenso erfolgreich wie Unix, da diese Abstraktionen gut zusammengearbeitet haben und /dev/nullam besten als Teil dieses Ganzen verstanden werden können.

PS: Es lohnt sich, sich die Unix-Version von "Alles ist eine Datei" anzuschauen, und zwar /dev/nullals erste Schritte zu einer flexibleren und leistungsfähigeren Verallgemeinerung der Metapher, die in vielen folgenden Systemen implementiert wurde.

Zum Beispiel mussten in Unix spezielle dateiähnliche Objekte wie /dev/nullim Kernel selbst implementiert werden, aber es hat sich herausgestellt, dass es nützlich genug ist, Funktionen in Datei- / Ordnerform bereitzustellen, die seitdem mehrere Systeme haben, die eine Möglichkeit für Programme bieten das zu tun.

Eines der ersten war das Betriebssystem Plan 9, das von einigen der gleichen Leute wie Unix entwickelt wurde. Später machte GNU Hurd mit seinen "Übersetzern" etwas Ähnliches. In der Zwischenzeit bekam Linux FUSE (das sich mittlerweile auch auf die anderen Mainstream-Systeme ausgebreitet hat).

Ich denke, es /dev/nullist ein Zeichengerät (das sich wie eine gewöhnliche Datei verhält) anstelle eines Programms aus Leistungsgründen .

Wenn es sich um ein Programm handeln würde, müsste das Programm geladen, gestartet, geplant, ausgeführt und anschließend gestoppt und entladen werden. Das einfache C-Programm, das Sie beschreiben, würde natürlich nicht viel Ressourcen verbrauchen, aber ich denke, es macht einen signifikanten Unterschied, wenn man eine große Anzahl (sagen wir Millionen) von Redirect / Piping-Aktionen in Betracht zieht, da Prozessmanagementvorgänge in großem Umfang kostspielig sind Sie beinhalten Kontextwechsel.

Eine andere Annahme: Das Weiterleiten in ein Programm erfordert die Zuweisung von Speicher durch das empfangende Programm (auch wenn es direkt danach verworfen wird). Wenn Sie also in das Tool weiterleiten, haben Sie den doppelten Speicherverbrauch, einmal im Sendeprogramm und einmal im Empfangsprogramm.

Abgesehen von "Alles ist eine Datei" und damit der Benutzerfreundlichkeit, auf der die meisten anderen Antworten basieren, gibt es auch Leistungsprobleme, wie @ user5626466 erwähnt.

Um dies in der Praxis zu zeigen, erstellen wir ein einfaches Programm mit dem Namen nullread.c:

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

und kompiliere es mit gcc -O2 -Wall -W nullread.c -o nullread

(Hinweis: Wir können lseek (2) nicht für Rohre verwenden. Daher muss das Rohr nur abgelesen werden, bis es leer ist.)

% 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

wohingegen /dev/nullwir mit der Standard- Dateiumleitung viel bessere Geschwindigkeiten erzielen (aufgrund der genannten Fakten: weniger Kontextwechsel, Kernel ignoriert nur Daten, anstatt sie zu kopieren usw.):

% 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

(dies sollte dort ein Kommentar sein, ist aber zu groß dafür und wäre völlig unlesbar)

Ihre Frage wird gestellt, als ob etwas vielleicht in der Einfachheit gewonnen würde, indem ein Nullprogramm anstelle einer Datei verwendet wird. Vielleicht können wir den Begriff "magische Dateien" loswerden und stattdessen nur "gewöhnliche Pfeifen" haben.

Aber bedenken Sie, eine Pipe ist auch eine Datei . Sie werden normalerweise nicht benannt und können daher nur über ihre Dateideskriptoren bearbeitet werden.

Betrachten Sie dieses etwas konstruierte Beispiel:

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

Mit der Prozessersetzung von Bash können wir dasselbe auf viel einfachere Weise erreichen:

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

Ersetzen Sie die grepfürecho und wir können unter der Decke sehen:

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

Das <(...) Konstrukt wird einfach durch einen Dateinamen ersetzt, und grep glaubt, dass es eine alte Datei öffnet. Es wird einfach nur benannt /dev/fd/63. Hier /dev/fdist ein magisches Verzeichnis, das Named Pipes für jeden Dateideskriptor erstellt, der von der Datei, die darauf zugreift, verwendet wird.

Wir könnten es weniger magisch mkfifomachen, eine Named Pipe zu lserstellen , die in und in allem auftaucht , genau wie eine gewöhnliche Datei:

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

Anderswo:

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

und siehe da, grep wird ausgeben foo.

Ich denke , wenn Sie Rohre und normale Dateien und spezielle Dateien wie / dev / null realisieren sind alle nur Dateien, es ist offensichtlich ein Null - Programm Umsetzung ist mehr komplex. Der Kernel muss Schreibvorgänge in eine Datei so oder so behandeln, aber im Fall von / dev / null kann er die Schreibvorgänge einfach auf den Boden fallen lassen, wohingegen er mit einer Pipe die Bytes tatsächlich an ein anderes Programm übertragen muss, das dies dann tun muss Lesen Sie sie tatsächlich.

Ich würde argumentieren, dass es ein Sicherheitsproblem gibt, das über historische Paradigmen und Leistungen hinausgeht. Die Begrenzung der Anzahl von Programmen mit privilegierten Ausführungsberechtigungen, egal wie einfach, ist ein grundlegender Grundsatz der Systemsicherheit. Ein Ersatz /dev/nullwäre sicherlich erforderlich, um solche Berechtigungen aufgrund der Verwendung durch Systemdienste zu haben. Moderne Sicherheits-Frameworks leisten hervorragende Arbeit, um Exploits zu verhindern, sind jedoch nicht narrensicher. Ein kernelgetriebenes Gerät, auf das als Datei zugegriffen wird, ist viel schwieriger auszunutzen.

Wie andere bereits ausgeführt haben, /dev/null handelt es sich um ein Programm, das aus einer Handvoll Codezeilen besteht. Es ist nur so, dass diese Codezeilen Teil des Kernels sind.

Um es klarer zu machen, hier ist die Linux-Implementierung: Ein Zeichengerät ruft Funktionen auf, wenn es gelesen oder geschrieben wird. Schreiben in /dev/nullAufrufe write_null , während Lesen in Aufrufe read_null , die hier registriert sind .

Buchstäblich eine Handvoll Codezeilen: Diese Funktionen tun nichts. Sie benötigen nur dann mehr Codezeilen als Finger auf Ihren Händen, wenn Sie andere Funktionen als Lesen und Schreiben zählen.

Ich hoffe, dass Sie auch die / dev / chargen / dev / zero und andere wie diese kennen, einschließlich / dev / null.

LINUX / UNIX stellt einige davon zur Verfügung, damit die Benutzer gut geschriebene Codefragen nutzen können.

Chargen wurde entwickelt, um ein spezifisches und sich wiederholendes Zeichenmuster zu generieren. Es ist recht schnell und würde die Grenzen serieller Geräte überschreiten und beim Debuggen von seriellen Protokollen helfen, die geschrieben wurden und bei einem Test oder einem anderen fehlgeschlagen sind.

Mit Zero können Sie eine vorhandene Datei füllen oder eine ganze Reihe von Nullen ausgeben

/ dev / null ist nur ein weiteres Tool mit der gleichen Idee.

Alle diese Tools in Ihrem Toolkit bedeuten, dass Sie die halbe Chance haben, ein vorhandenes Programm dazu zu bringen, etwas Einzigartiges zu tun, ohne Rücksicht auf ihre (Ihre speziellen Bedürfnisse) als Geräte oder zum Ersetzen von Dateien

Lass uns einen Wettbewerb veranstalten, um zu sehen, wer mit nur wenigen Zeichengeräten in deiner LINUX-Version das aufregendste Ergebnis erzielen kann.