Perché / dev / null è un file? Perché la sua funzione non è implementata come un semplice programma?

Sto cercando di capire il concetto di file speciali su Linux. Tuttavia, avere un file speciale in /devsembra sciocco quando la sua funzione potrebbe essere implementata da una manciata di righe in C a mia conoscenza.

Inoltre potresti usarlo più o meno allo stesso modo, ad esempio eseguendo il piping nullinvece di reindirizzare /dev/null. C'è un motivo specifico per averlo come file? Fare un file non causa molti altri problemi come troppi programmi che accedono allo stesso file?

Oltre ai vantaggi in termini di prestazioni derivanti dall'uso di un dispositivo speciale per i personaggi, il vantaggio principale è la modularità . / dev / null può essere utilizzato in quasi tutti i contesti in cui è previsto un file, non solo nelle pipeline di shell. Considera i programmi che accettano i file come parametri della riga di comando.

# 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

Questi sono tutti casi in cui l'utilizzo di un programma come sorgente o sink sarebbe estremamente complicato. Anche nel caso della pipeline della shell, stdout e stderr possono essere reindirizzati ai file in modo indipendente, cosa difficile da fare con gli eseguibili come sink:

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

In tutta onestà, non è un file normale di per sé; è un dispositivo speciale per i personaggi :

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

Funzionando come un dispositivo piuttosto che come un file o programma significa che è un'operazione più semplice reindirizzare l'input o l'output da esso, in quanto può essere collegato a qualsiasi descrittore di file, incluso input / output / errore standard.

Sospetto che il perché abbia molto a che fare con la visione / il design che ha plasmato Unix (e di conseguenza Linux) e i vantaggi che ne derivano.

Senza dubbio c'è un vantaggio non trascurabile in termini di prestazioni nel non avviare un processo aggiuntivo, ma penso che ci sia molto altro: Early Unix aveva una metafora "tutto è un file", che ha un vantaggio non ovvio ma elegante se si guarda dal punto di vista del sistema, piuttosto che dal punto di vista dello script di shell.

Supponi di avere il tuo nullprogramma da riga di comando e /dev/nullil nodo del dispositivo. Dal punto di vista della shell-scripting, il foo | nullprogramma è davvero utile e conveniente , e foo >/dev/nullrichiede un po 'più di tempo per scrivere e può sembrare strano.

Ma ecco due esercizi:

1. Facciamo l'attuazione del programma nullutilizzando gli strumenti Unix esistenti e /dev/null- facile: cat >/dev/null. Fatto.

2. Puoi implementare /dev/nullin termini di null?

Hai perfettamente ragione sul fatto che il codice C per scartare l'input sia banale, quindi potrebbe non essere ancora chiaro il motivo per cui è utile avere un file virtuale disponibile per l'attività.

Considera: quasi tutti i linguaggi di programmazione hanno già bisogno di lavorare con file, descrittori di file e percorsi di file, perché facevano parte del paradigma "tutto è un file" di Unix sin dall'inizio.

Se tutto ciò che hai sono programmi che scrivono su stdout, beh, al programma non importa se li reindirizzi in un file virtuale che ingoia tutte le scritture o una pipe in un programma che ingoia tutte le scritture.

Ora, se hai programmi che prendono percorsi di file per leggere o scrivere dati (cosa che la maggior parte dei programmi fa) - e vuoi aggiungere la funzionalità "input vuoto" o "scartare questo output" a quei programmi - beh, con /dev/nullquello viene gratis.

Si noti che l'eleganza di ciò è che riduce la complessità del codice di tutti i programmi coinvolti - per ogni caso d'uso comune ma speciale che il sistema può fornire come "file" con un "nome file" effettivo, il codice può evitare l'aggiunta di comandi personalizzati -line opzioni e percorsi di codice personalizzati da gestire.

Una buona ingegneria del software dipende spesso dalla ricerca di metafore buone o "naturali" per astrarre qualche elemento di un problema in un modo che diventa più facile da pensare ma rimane flessibile , in modo da poter risolvere sostanzialmente la stessa gamma di problemi di livello superiore senza dover dedicare costantemente tempo ed energie mentali alla reimplementazione di soluzioni agli stessi problemi di livello inferiore.

"Tutto è un file" sembra essere una tale metafora per accedere alle risorse: si chiama openun determinato percorso in uno spazio dei nomi gerarchico, si ottiene un riferimento (descrittore di file) all'oggetto e si può reade write, ecc., Sui descrittori di file. Il tuo stdin / stdout / stderr sono anche descrittori di file che sono appena stati pre-aperti per te. Le tue pipe sono solo file e descrittori di file e il reindirizzamento dei file ti consente di incollare tutti questi pezzi insieme.

Unix ha avuto successo tanto quanto in parte grazie al modo in cui queste astrazioni hanno funzionato insieme, ed /dev/nullè meglio compreso come parte di tutto.

PS Vale la pena guardare la versione Unix di "tutto è un file" e cose come /dev/nulli primi passi verso una generalizzazione più flessibile e potente della metafora che è stata implementata in molti sistemi che seguirono.

Ad esempio, in Unix oggetti simili /dev/nulla file simili dovevano essere implementati nel kernel stesso, ma si scopre che è abbastanza utile esporre funzionalità in forma di file / cartella che da allora sono stati creati più sistemi che forniscono un modo per i programmi fare quello.

Uno dei primi è stato il sistema operativo Plan 9, realizzato da alcune delle stesse persone che hanno creato Unix. Più tardi, GNU Hurd ha fatto qualcosa di simile con i suoi "traduttori". Nel frattempo, Linux ha finito per ottenere FUSE (che ormai si è diffuso anche agli altri sistemi tradizionali).

Penso che /dev/nullsia un dispositivo a caratteri (che si comporta come un normale file) invece di un programma per motivi di prestazioni .

Se fosse un programma richiederebbe il caricamento, l'avvio, la pianificazione, l'esecuzione e successivamente l'arresto e lo scaricamento del programma. Il semplice programma C che stai descrivendo ovviamente non consumerebbe molte risorse, ma penso che faccia una differenza significativa quando si considera un gran numero (diciamo milioni) di azioni di reindirizzamento / piping poiché le operazioni di gestione dei processi sono costose su larga scala come coinvolgono cambi di contesto.

Un altro presupposto: il piping in un programma richiede che la memoria sia allocata dal programma ricevente (anche se viene scartata subito dopo). Quindi se installi nello strumento hai il doppio consumo di memoria, una volta sul programma di invio e di nuovo sul programma di ricezione.

Oltre a "tutto è un file" e quindi facilità d'uso ovunque su cui si basano la maggior parte delle altre risposte, c'è anche un problema di prestazioni come menzionato da @ user5626466.

Per mostrare in pratica, creeremo un semplice programma chiamato nullread.c:

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

e compilarlo con gcc -O2 -Wall -W nullread.c -o nullread

(Nota: non possiamo usare lseek (2) sui tubi, quindi l'unico modo per drenare il tubo è leggere da esso fino a quando non è vuoto).

% 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

considerando che con /dev/nullil reindirizzamento dei file standard otteniamo velocità molto migliori (a causa dei fatti menzionati: meno cambio di contesto, kernel semplicemente ignorando i dati invece di copiarli ecc.):

% 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

(questo dovrebbe essere un commento lì, ma è troppo grande per questo e sarebbe completamente illeggibile)

La tua domanda è posta come se qualcosa potesse essere guadagnato forse nella semplicità usando un programma null al posto di un file. Forse possiamo liberarci del concetto di "file magici" e invece avere solo "pipe ordinarie".

Ma considera, anche una pipe è un file . Normalmente non hanno un nome e quindi possono essere manipolati solo attraverso i loro descrittori di file.

Considera questo esempio in qualche modo inventato:

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

Usando la sostituzione del processo di Bash possiamo ottenere la stessa cosa in un modo più indiretto:

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

Sostituisci il grepper echoe possiamo vedere sotto le copertine:

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

Il <(...)costrutto è appena sostituito con un nome file, e grep pensa che stia aprendo qualsiasi vecchio file, sembra solo che sia chiamato /dev/fd/63. Qui, /dev/fdc'è una directory magica che crea le named pipe per ogni descrittore di file posseduto dal file che vi accede.

Potremmo renderlo meno magico con la mkfifocreazione di una pipe denominata che si presenta in lse tutto, proprio come un normale file:

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

Altrove:

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

ed ecco, grep produrrà foo.

Penso che una volta che ti rendi conto che pipe e file regolari e file speciali come / dev / null sono tutti solo file, è evidente che implementare un programma null è più complesso. Il kernel deve gestire le scritture in un file in entrambi i modi, ma nel caso di / dev / null può semplicemente rilasciare le scritture sul pavimento, mentre con una pipe deve effettivamente trasferire i byte su un altro programma, che quindi deve li leggo davvero.

Direi che esiste un problema di sicurezza al di là dei paradigmi storici e delle prestazioni. Limitare il numero di programmi con credenziali di esecuzione privilegiate, non importa quanto semplice, è un principio fondamentale della sicurezza del sistema. Una sostituzione /dev/nullsarebbe certamente richiesta per avere tali privilegi dovuti all'uso da parte dei servizi di sistema. I moderni quadri di sicurezza svolgono un ottimo lavoro nella prevenzione degli exploit, ma non sono infallibili. Un dispositivo guidato dal kernel a cui si accede come file è molto più difficile da sfruttare.

Come altri hanno già sottolineato, /dev/null è un programma composto da una manciata di righe di codice. È solo che queste righe di codice fanno parte del kernel.

Per renderlo più chiaro, ecco l'implementazione di Linux: un dispositivo a caratteri chiama funzioni quando viene letto o scritto. Scrivere sulle /dev/nullchiamate write_null , durante la lettura delle chiamate read_null , registrato qui .

Letteralmente una manciata di righe di codice: queste funzioni non fanno nulla. Avresti bisogno di più righe di codice rispetto alle dita delle mani solo se conti funzioni diverse da leggere e scrivere.

Spero che tu sia anche a conoscenza di / dev / chargen / dev / zero e di altri come loro, incluso / dev / null.

LINUX / UNIX ne ha messi a disposizione alcuni in modo che le persone possano fare buon uso di FRAGMEnTS CODICE SCRITTO BEN.

Chargen è progettato per generare un modello specifico e ripetuto di caratteri: è abbastanza veloce e spingerebbe i limiti dei dispositivi seriali e aiuterebbe a eseguire il debug dei protocolli seriali che erano stati scritti e fallivano alcuni test o altro.

Zero è progettato per popolare un file esistente o generare molti zero

/ dev / null è solo un altro strumento con la stessa idea in mente.

Tutti questi strumenti nel tuo toolkit significa che hai la metà delle possibilità di far fare a un programma esistente qualcosa di unico, indipendentemente dal loro (tuo bisogno specifico) come dispositivo o sostituzione di file

Consente di impostare un concorso per vedere chi può produrre il risultato più emozionante dati solo i pochi dispositivi personaggio nella tua versione di LINUX.