Je suis surtout curieux, mais pourquoi n'y a-t-il pas d'interfaces réseau dans /dev ?
Existe-t-il d'autres types d'appareils qui ne sont pas représentés en tant que nœud sous /dev ?
Réponse acceptée :
Sur de nombreux appareils, les principales opérations consistent à envoyer des octets de l'ordinateur à un périphérique ou à recevoir des octets d'un périphérique sur l'ordinateur. De tels dispositifs sont similaires aux tuyaux et fonctionnent bien comme dispositifs de caractères. Pour les opérations autres que la lecture et l'écriture (telles que le contrôle de flux sur une ligne série), l'appareil fournit des commandes ad hoc appelées ioctl.
Certains périphériques ressemblent beaucoup à des fichiers normaux :ils sont constitués d'un nombre fini d'octets, et ce que vous écrivez à une position donnée peut ensuite être lu à partir de la même position. Ces appareils sont appelés appareils de bloc.
Les interfaces réseau sont plus complexes :ce qu'elles lisent et écrivent ne sont pas des octets mais des paquets. Alors qu'il serait toujours possible d'utiliser l'interface habituelle avec read et write , ce serait gênant :probablement chaque appel à write enverrait un paquet, et chaque appel à read recevrait un paquet (et si la mémoire tampon est trop petite pour que le paquet puisse tenir, le paquet serait perdu).
Les interfaces réseau peuvent exister en tant que périphériques fournissant uniquement ioctl . En fait, c'est ce que font certaines variantes d'Unix, mais pas Linux. Il y a un certain avantage à cette approche; par exemple, sous Linux, les interfaces réseau pourraient tirer parti d'udev. Mais les avantages sont limités, c'est pourquoi cela n'a pas été fait.
La plupart des applications liées au réseau ne se soucient pas des interfaces réseau individuelles, elles fonctionnent à un niveau supérieur. Par exemple, un navigateur Web souhaite établir des connexions TCP et un serveur Web souhaite écouter les connexions TCP. À cette fin, ce qui serait utile, ce sont des appareils pour les protocoles réseau de haut niveau, par exemple
{ echo $'GET http://www.google.com/ HTTP/1.0r';
echo $'Host: www.google.comr';
echo $'r' >&0; cat; } <>/dev/tcp/www.google.com/80
En fait, ksh et bash fournissent une telle interface pour les clients TCP et UDP. En général, cependant, les applications réseau sont plus complexes que les applications d'accès aux fichiers. Alors que la plupart des échanges de données sont effectués avec des appels analogues à read et write , l'établissement de la connexion nécessite plus d'informations qu'un simple nom de fichier. Par exemple, l'écoute des connexions TCP s'effectue en deux étapes :une à effectuer lorsque le serveur commence à écouter et une à chaque fois qu'un client se connecte. Ces étapes supplémentaires ne s'intègrent pas bien dans l'API de fichier, ce qui est la principale raison pour laquelle la mise en réseau a sa propre API.
Une autre classe d'appareils qui n'a généralement pas d'entrées dans /dev sous Linux (mais le fait sur certaines autres variantes d'unix) est les adaptateurs vidéo. En principe, de simples adaptateurs vidéo pourraient être exposés en tant que dispositifs de tampon de trame, qui pourraient être des dispositifs de bloc constitués de blocs représentant la couleur de chaque pixel. Les adaptateurs vidéo accélérés pourraient être représentés comme des périphériques de caractères sur lesquels les applications envoient des commandes. Ici, l'inconvénient de l'interface du périphérique est qu'elle est lente :l'application d'affichage (en pratique, un serveur X) devrait faire des appels au noyau chaque fois qu'elle affiche quoi que ce soit. Ce qui se passe à la place, c'est que le serveur X écrit principalement directement dans la mémoire de la carte vidéo, car c'est plus rapide.