Pourquoi / dev / null est-il un fichier? Pourquoi sa fonction n'est-elle pas implémentée comme un simple programme?

J'essaie de comprendre le concept de fichiers spéciaux sous Linux. Toutefois, /devà ma connaissance , avoir un fichier spécial dans le fichier semble tout à fait ridicule, alors que sa fonction pourrait être mise en œuvre par une poignée de lignes en C.

De plus, vous pouvez l'utiliser à peu près de la même manière, c.-à- nulld /dev/null. Y a-t-il une raison spécifique de l'avoir en fichier? Faire un fichier ne cause pas beaucoup de problèmes comme trop de programmes accédant au même fichier?

Outre les avantages en termes de performances liés à l'utilisation d'un périphérique spécial caractères, le principal avantage est la modularité . / dev / null peut être utilisé dans presque tous les contextes dans lesquels un fichier est attendu, pas seulement dans les pipelines de shell. Considérez les programmes qui acceptent les fichiers en tant que paramètres de ligne de commande.

# 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

Ce sont tous des cas où l'utilisation d'un programme en tant que source ou puits serait extrêmement fastidieuse. Même dans le cas du pipeline shell, stdout et stderr peuvent être redirigés indépendamment vers des fichiers, ce qui est difficile à faire avec des exécutables en tant que récepteurs:

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

En toute justice, ce n'est pas un fichier régulier en soi; c'est un dispositif spécial de personnage :

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

Son fonctionnement en tant que périphérique plutôt qu’en tant que fichier ou programme signifie qu’il est plus simple de rediriger ses entrées ou ses sorties, car il peut être attaché à n’importe quel descripteur de fichier, y compris les entrées / sorties / erreurs standard.

Je soupçonne que le pourquoi a beaucoup à faire avec la vision / conception qui a façonné Unix (et par conséquent Linux), et les avantages qui en découlent.

Nul doute qu’il ya un avantage non négligeable sur le plan des performances à ne pas créer un processus supplémentaire, mais je pense qu’il ya plus à faire: Early Unix avait une métaphore "tout est un fichier", ce qui présente un avantage non évident mais élégant si vous le regardez. cela du point de vue du système plutôt que du point de vue des scripts shell.

Supposons que vous ayez votre nullprogramme de ligne de commande et /dev/nullle nœud de périphérique. Du point de vue des scripts shell, le foo | nullprogramme est réellement utile et pratique , et foo >/dev/nullprend un peu plus de temps à taper et peut sembler étrange.

Mais voici deux exercices:

1. Nous allons mettre en œuvre le programme en nullutilisant des outils Unix existants et /dev/null- facile: cat >/dev/null. Terminé.

2. Pouvez-vous mettre /dev/nullen œuvre en termes de null?

Vous avez absolument raison de dire que le code C destiné à supprimer une entrée est trivial, il est donc difficile de comprendre pourquoi il est utile de disposer d'un fichier virtuel pour la tâche.

Prenez en compte que presque tous les langages de programmation doivent déjà utiliser des fichiers, des descripteurs de fichiers et des chemins de fichiers, car ils faisaient partie du paradigme d'Unix "tout est un fichier" depuis le début.

Si tout ce que vous avez sont des programmes qui écrivent sur stdout, eh bien, le programme ne se soucie pas de les rediriger vers un fichier virtuel qui englobe toutes les écritures ou un canal vers un programme qui englobe toutes les écritures.

Maintenant, si vous avez des programmes qui utilisent des chemins de fichiers pour lire ou écrire des données (ce que font la plupart des programmes), et que vous souhaitez ajouter une fonctionnalité "entrée vide" ou "supprimer cette sortie" à ces programmes, /dev/nullcela est gratuit.

Notez que son élégance est de réduire la complexité du code de tous les programmes impliqués - pour chaque cas d'utilisation commun mais particulier que votre système peut fournir en tant que "fichier" avec un "nom de fichier" réel, votre code peut éviter d'ajouter une commande personnalisée. -ligne les options et les chemins de code personnalisés à gérer.

Une bonne ingénierie logicielle dépend souvent de la recherche de métaphores «naturelles» pour résumer certains éléments d’un problème d’une manière qui facilite la réflexion mais reste souple , de sorte que vous puissiez résoudre pratiquement le même éventail de problèmes de niveau supérieur sans avoir à consacrer temps et énergie mentale à réimplémenter en permanence des solutions aux mêmes problèmes de niveau inférieur.

« Tout est un fichier » semble être une telle métaphore pour l' accès aux ressources: Vous appelez opend'un chemin donné dans un espace de noms heirarchical, en obtenant une référence (descripteur de fichier) à l'objet, et vous pouvez readet write, etc sur les descripteurs de fichiers. Votre stdin / stdout / stderr sont également des descripteurs de fichier qui viennent d’être pré-ouverts pour vous. Vos canaux ne sont que des fichiers et des descripteurs de fichiers, et la redirection de fichiers vous permet de coller tous ces éléments ensemble.

Unix a tout autant réussi en partie à cause de la manière dont ces abstractions ont bien fonctionné et /dev/nullest mieux compris en tant que partie intégrante de cet ensemble.

Post-scriptum Il convient de regarder la version Unix de "Tout est un fichier", entre autres, /dev/nullcomme les premiers pas vers une généralisation plus souple et plus puissante de la métaphore mise en œuvre dans de nombreux systèmes qui ont suivi.

Par exemple, sous Unix, des objets spéciaux de type fichier, tels que ceux-ci, /dev/nulldevaient être implémentés dans le noyau lui-même, mais il s'avère assez utile d’exposer les fonctionnalités sous forme de fichier / dossier qui, depuis lors, ont permis de créer plusieurs systèmes qui permettent aux programmes pour faire ça.

L'un des premiers était le système d'exploitation Plan 9, créé par les mêmes personnes qui ont créé Unix. Plus tard, GNU Hurd a fait quelque chose de similaire avec ses "traducteurs". Pendant ce temps, Linux finissait par obtenir FUSE (qui s’est également propagé aux autres systèmes traditionnels).

Je pense /dev/nullest un périphérique de caractère (qui se comporte comme un fichier ordinaire) au lieu d'un programme pour des raisons de performances .

S'il s'agissait d'un programme, il faudrait charger, démarrer, planifier, exécuter, puis arrêter et décharger le programme. Le programme C simple que vous décrivez ne consomme évidemment pas beaucoup de ressources, mais je pense que cela fait une différence significative quand on considère un grand nombre (disons des millions) d’actions de redirection / canalisation, car les opérations de gestion de processus sont coûteuses à grande échelle, car ils impliquent des changements de contexte.

Autre hypothèse: la canalisation dans un programme nécessite que la mémoire alloue de la mémoire (même si elle est immédiatement supprimée). Donc, si vous dirigez dans l'outil, vous avez la double consommation de mémoire, une fois sur le programme d'envoi et à nouveau sur le programme de réception.

En plus de "tout est un fichier" et donc de la facilité d'utilisation partout où la plupart des autres réponses sont basées, il y a aussi un problème de performances mentionné par @ user5626466.

Pour montrer en pratique, nous allons créer un programme simple appelé nullread.c:

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

et compiler avec gcc -O2 -Wall -W nullread.c -o nullread

(Remarque: nous ne pouvons pas utiliser lseek (2) sur les tuyaux, le seul moyen de drainer le tuyau consiste à le lire jusqu'à ce qu'il soit vide).

% 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

alors qu'avec /dev/nullla redirection de fichiers standard , nous obtenons des vitesses bien meilleures (en raison des faits mentionnés: moins de changements de contexte, le noyau ignore simplement les données au lieu de les copier, etc.):

% 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

(cela devrait être un commentaire là-bas, mais c'est trop gros pour ça et serait complètement illisible)

Votre question est posée comme si quelque chose serait gagné peut-être dans la simplicité en utilisant un programme nul à la place d'un fichier. Peut-être pourrions-nous nous débarrasser de la notion de "fichiers magiques" et utiliser à la place des "canaux ordinaires".

Mais considérons qu'un tuyau est aussi un fichier . Ils ne sont normalement pas nommés et ne peuvent donc être manipulés que par leurs descripteurs de fichier.

Considérez cet exemple quelque peu artificiel:

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

En utilisant la substitution de processus de Bash, nous pouvons accomplir la même chose de manière plus détournée:

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

Remplacez le greppour echoet on peut voir sous les couvertures:

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

La <(...)construction est simplement remplacée par un nom de fichier, et grep pense que tout fichier ancien est ouvert, il se trouve que son nom est nommé /dev/fd/63. Voici /dev/fdun répertoire magique qui crée des canaux nommés pour chaque descripteur de fichier possédé par le fichier qui y accède.

Nous pourrions faire moins de magie mkfifoen faisant un tuyau nommé qui apparaît dans lset tout, comme un fichier ordinaire:

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

Autre part:

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

et voici, grep va sortir foo.

Je pense qu'une fois que vous avez compris que les pipes, les fichiers ordinaires et les fichiers spéciaux tels que / dev / null ne sont que des fichiers, il est évident que la mise en oeuvre d'un programme null est plus complexe. Le noyau doit gérer les écritures dans un fichier de toute façon, mais dans le cas de / dev / null, il peut simplement laisser tomber les écritures sur le sol, tandis qu'avec un tube il doit réellement transférer les octets vers un autre programme, qui doit ensuite effectivement les lire.

Je dirais qu'il existe un problème de sécurité allant au-delà des paradigmes et des performances historiques. Limiter le nombre de programmes avec des informations d'identification d'exécution privilégiées, aussi simple soit-il, est un principe fondamental de la sécurité du système. Un remplaçant /dev/nullserait certainement nécessaire pour disposer de tels privilèges en raison de son utilisation par les services du système. Les frameworks de sécurité modernes font un excellent travail de prévention des exploits, mais ils ne sont pas infaillibles. Un périphérique piloté par le noyau et accessible en tant que fichier est beaucoup plus difficile à exploiter.

Comme d'autres l'ont déjà souligné, /dev/null est un programme constitué d'une poignée de lignes de code. C'est juste que ces lignes de code font partie du noyau.

Pour être plus clair, voici l’implémentation Linux: un périphérique caractère appelle des fonctions lorsqu’il est lu ou écrit. Écrire pour /dev/nullappeler write_null , tout en lisant les appels read_null , enregistrés ici .

Littéralement une poignée de lignes de code: ces fonctions ne font rien. Vous aurez besoin de plus de lignes de code que de doigts sur vos mains uniquement si vous comptez des fonctions autres que lire et écrire.

J'espère que vous connaissez également le répertoire / dev / chargen / dev / zero et d’autres, comme / dev / null.

LINUX / UNIX en propose quelques-uns - mis à disposition pour que les utilisateurs puissent bien utiliser les fragments de code WELL WRITTEN CODE FrAGMEnTS.

Chargen est conçu pour générer un motif spécifique et répété de caractères - il est assez rapide et repousserait les limites des périphériques série et aiderait à déboguer les protocoles série écrits et ayant échoué à un test ou à un autre.

Zero est conçu pour peupler un fichier existant ou générer beaucoup de zéros.

/ dev / null est juste un autre outil avec la même idée en tête.

Tous ces outils de votre boîte à outils signifient que vous avez une chance sur deux de faire en sorte qu'un programme existant fasse quelque chose d'unique, indépendamment de son (votre besoin spécifique) en tant que périphériques ou fichiers de remplacement.

Permet de mettre en place un concours pour voir qui peut produire le résultat le plus excitant compte tenu du nombre limité de périphériques de personnage dans votre version de LINUX.