Pourquoi les interfaces réseau dans / dev ne sont-elles pas comme les autres périphériques?

70

Je suis surtout curieux, mais pourquoi les interfaces réseau ne sont-elles pas dans / dev? Existe-t-il d'autres types de périphériques qui ne sont pas représentés en tant que nœud sous / dev?

devices udev

— andyortlieb
source

2

J'ai vu au moins un article / discours sur le fait que tout dans Unix n'est pas un fichier malgré le mantra, et il cite ce problème. Je ne le trouve pas maintenant, mais c’était probablement un article sur Plan 9 ou GNU Hurd.

— Shawn J. Goff

3

Au moins sous Solaris, il existe des périphériques d'interface réseau sous / dev (/ devices réellement).

— juillet

2

Tout ce qui est sous Unix en tant que fichier ne signifie pas nécessairement qu'il se comporte de cette manière pour tout le monde utilisateur, mais simplement que les API sous-jacentes fonctionnent correctement et uniformément sur les descripteurs de fichier. Lorsque vous ouvrez une prise, par exemple, vous pouvez utiliser read()et de write()la même façon que vous le feriez sur un fichier, mais les fonctions d'utilité recv()et send()faire beaucoup plus démarches pour vous.

— Jgoldschrafe

1

C'était une question que je me posais depuis des années. Merci d'avoir demandé et aux gens d'avoir répondu!

— Dolanor

43

Sur de nombreux périphériques, les opérations principales consistent à envoyer des octets de l'ordinateur à un périphérique ou à recevoir des octets d'un périphérique de l'ordinateur. De tels dispositifs sont similaires aux pipes et fonctionnent bien en tant que dispositifs pour les personnages . Pour les opérations qui ne lisent et n'écrivent pas (comme le contrôle de flux sur une ligne série), le périphérique fournit des commandes ad-hoc appelées ioctl .

Certains périphériques ressemblent beaucoup à des fichiers normaux: ils sont composé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 périphériques sont appelés des périphériques en mode bloc .

Les interfaces réseau sont plus complexes: ce qu’elles lisent et écrivent n’est pas des octets mais des paquets. Même s’il serait toujours possible d’utiliser l’interface habituelle avec readet write, ce serait gênant: chaque appel à writeenvoyer un paquet, et chaque appel à readrecevoir un paquet (et si le tampon est trop petit pour tenir dans le paquet, 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 Unix, mais pas Linux. Cette approche présente certains avantages. par exemple, sous Linux, les interfaces réseau pourraient exploiter 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 travaillent à un niveau supérieur. Par exemple, un navigateur Web souhaite établir des connexions TCP et un serveur Web souhaite écouter les connexions TCP. Pour ce faire, il serait utile de disposer de périphériques pour les protocoles réseau de haut niveau, par exemple:

{ echo $'GET http://www.google.com/ HTTP/1.0\r';
  echo $'Host: www.google.com\r';
  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, toutefois, 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 à readet write, l'établissement de la connexion nécessite plus d'informations qu'un simple nom de fichier. Par exemple, l'écoute de connexions TCP nécessite deux étapes: une à exécuter lorsque le serveur commence à écouter et une à effectuer à chaque fois qu'un client se connecte. De telles étapes supplémentaires ne s'intègrent pas bien dans l'API de fichier. C'est la raison principale pour laquelle la mise en réseau a sa propre API.

Les /devadaptateurs vidéo sont une autre classe de périphériques qui ne possèdent généralement pas d'entrées sous Linux (mais sur d'autres variantes unix). 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 blocage constitués de blocs représentant la couleur de chaque pixel. Les cartes vidéo accélérées peuvent être représentées comme des périphériques de caractères sur lesquels les applications envoient des commandes. Ici, l’inconvénient de l’interface de périphérique est sa lenteur: l’application qui affiche (en pratique, un serveur X) aurait besoin d’appeler le noyau chaque fois qu’elle affiche quelque chose. Au lieu de cela, le serveur X écrit la plupart du temps directement dans la mémoire de la carte vidéo, car elle est plus rapide.

— Gilles, arrête de faire le mal
source

2

En fait, les adaptateurs vidéo accélérés sont exportés sous forme de chardevs via DRI sous Linux. Les opérations d'E / S sur fichier ne sont pas nécessairement read/ writenon plus; vous pouvez utiliser mmappour les fichiers mappés et l'accès direct à la mémoire de l'appareil.

— minmaxavg

11

Vous pouvez le trouver dans le /sys/class/netrépertoire. it it it Lien symbolique vers un autre fichier /sys/device/../../, voici la sortie de ma machine virtuelle (noyau Linux 3.10). Et vous pouvez utiliser la commande udevadm info <filename>pour examiner son attribut

lrwxrwxrwx. 1 root root 0 Apr  3 13:38 ens33 -> ../../devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33

— chaoqun lu
source

Bienvenue chez U & L. Utilisez toujours des citations arrières autour du code en ligne, en particulier si vous utilisez <>autrement, cela sera interprété comme un balisage. (vous voudrez peut-être aussi changer votre nom pour commencer par une transcription ASCII, car les personnes utilisant un clavier simple auront des difficultés à saisir le premier caractère de votre nom en réponse à vos commentaires.)

— Anthon

9

La méthode TLI (Transport Level Interface) AT & T / Solaris pour la mise en réseau TCP / IP comporte des fichiers spéciaux tels que "/ dev / tcp" ou "/ dev / udp". Le programmeur ouvre ce fichier spécial pour obtenir un socket d'une famille de protocoles appropriée. Je pense que c'est pourquoi vous devez avoir "-lnsl" lors de la compilation d'un programme qui utilise des sockets sur Solaris: en dessous de tout cela, il s'agit de TLI.

— Bruce Ediger
source

4

Linux a également /dev/tcpet /dev/udp, bien que la plupart des noyaux l’ait désactivée.

— bahamat

3

Alors que, traditionnellement, Linux n’était pas entièrement compilable avec posix, encore moins de suivre tout type de standards Open Group (en dehors peut-être de LSB). Il y a eu des tentatives pour porter plus de fonctionnalités UNIX sous Linux.

Glendix est un de ces projets qui offre un port du système de fichiers virtuel / net de Plan9 qui vous permet de faire ce que vous décrivez.

Système de fichiers port / net de Plan9 sur Linux

— Dwight Spencer
source