D'ailleurs, qu'est-ce qui n'allait pas exactement avec un tas de fichiers statiques /dev? C'est apparemment assez insatisfaisant pour les développeurs d'avoir réinventé cette roue par mon compte 3 fois maintenant ( devfs-> udev + HAL-> udev), et maintenant, apparemment, il entre également dans le Grand Unified Init Program, donc quatre fois.

Je me souviens quand j'ai commencé à utiliser Linux il y a des années, étant surpris que, malgré les affirmations selon lesquelles "tout est un fichier", il n'y en ait pas /dev/eth0(cela avait plus de sens, car ce n'est pas un périphérique de type char ou bloc - bien qu'un type de périphérique "paquet" serait intéressant ...). Compte tenu de cela, pourquoi le programme qui gère l'arborescence des fichiers de caractères et de blocs est-il également responsable des périphériques réseau? J'ai vu de vagues références à la "flexibilité", mais qu'est-ce que cela ajoute par rapport à ce que, disons, ifconfig (8) fait en regardant simplement /proc/net/dev? Je sais, par exemple, que NetworkManager ne sera pas dans Net ou OpenBSD de sitôt parce que cela dépend udevduquel aucune équipe ne veut écrire; ce que je ne fais pas/devqui sont déjà exposés de multiples façons par le noyau (et aucun d'eux /dev!).

Est-ce juste à cause du branchement à chaud? Y a-t-il eu des problèmes avec le noyau simplement en écoutant les bus physiques et en chargeant les modules appropriés sur un message "périphérique ajouté"? Ou, Dieu nous en préserve, l'administrateur en tant que tel? Je me souviens qu'au début des années 2000, mes serveurs initialisaient parfois leurs cartes réseau dans un ordre inattendu, et je suppose qu'il est logique que cette dénomination soit décidée dans le pays utilisateur (même si ce n'était pas très difficile à corriger à l'époque), mais cela ressemble à un marteau pour un cafard. (Ou peut-être que ce problème frappe des cas d'utilisation auxquels je ne pense pas beaucoup plus dur que les serveurs ou les PC montés en rack, ce qui est mon expérience.)

Donc, pour énoncer clairement ma question: quels problèmes udev résout-il réellement et comment devfs, HAL et / ou un ancien fichier ordinaire n'ont-ils pas pu les résoudre? Y a-t-il une raison particulière pour que tant de choses différentes (branchement à chaud, gestion générale des périphériques, gestion des périphériques réseau, dénomination des périphériques, priorité des pilotes, etc.) soient toutes un seul programme?

Deux autres choses: le passage de Linux à l'entreprise et à d'autres grands serveurs exposait la statique /devà être brisée. L'avancement de la technologie, à la fois dans les consommateurs et les entreprises, exposait statique / dev comme une blague. [Cette réponse remplit davantage la trame de fond, pas particulièrement pourquoi devfs a été remplacé par udev].

Épuisement de l'espace des nombres majeurs et mineurs

/devles fichiers sont identifiés à l'intérieur du noyau par leur numéro majeur et mineur. Le noyau ne s'est jamais soucié du nom (et vous pourriez, par exemple, mv /dev/sda /dev/disk-1et il continuerait à fonctionner, bien que les programmes ne sachent pas où le trouver).

Avec un statique /dev, vous devez attribuer un numéro majeur / mineur à chaque appareil potentiel qui pourrait exister. Ces numéros doivent être uniques à l'échelle mondiale, car ils sont expédiés dans le cadre de distributions, et non créés à la demande. Le problème est qu'ils sont chacun des nombres de 8 bits - la plage est de 0 à 255.

À l'origine, par exemple, Linux a commencé avec 8,0 étant sda, 8,1 étant sda1, 8,16 étant sdb, etc. Mais les gens continuaient d'ajouter de plus en plus de disques aux machines, surtout quand on considère des choses comme le Fibre Channel. Donc, à un moment donné, des nombres majeurs 65–71 ont été ajoutés pour plus de disques. Plus tard, les nombres majeurs 128-135. Et pourtant, les gens voulaient toujours plus de disques ...

Et les formats de table de partition comme GPT sont apparus, prenant en charge plus de partitions par disque. Et bien sûr, d'autres appareils mangeaient dans l'espace numérique: divers contrôleurs RAID, gestion du volume logique, etc.

Le résultat final peut être vu dans la liste des périphériques LANANA Linux . Si vous regardez la liste 2.6 (la seule qui existe toujours), une grande partie des numéros de bloc jusqu'à 200 (max: 255) sont utilisés. De toute évidence, les chiffres seraient épuisés.

Passer à un plus grand nombre n'a pas été facile. Il change le noyau ABI. Selon le système de fichiers, il modifie la disposition sur le disque. Mais, bien sûr, la plupart de ces périphériques n'existaient sur aucun système, même celui qui était (par exemple) à court de disques SCSI avait probablement beaucoup de choses gratuites - il n'avait probablement pas besoin d'un disque dur IBM XT, par exemple.

Avec une dynamique /dev, la distribution n'a pas à expédier les numéros de périphérique. Ils ne doivent plus être uniques au monde. Ils n'ont même pas besoin d'être uniques à travers les bottes.

Les noms des appareils étaient imprévisibles

Auparavant, il était très facile d'attribuer un numéro à tout. Une carte avait deux canaux IDE; chaque canal IDE prend en charge un maître et un esclave. Vous pouvez attribuer dans l'ordre des canaux et dans l'ordre maître puis esclave. Devient hdaainsi le premier canal, maître; hdbpremier canal, esclave; hdcdeuxième canal, maître; etc. Celles-ci étaient prévisibles et stables. Ils peuvent changer si vous ajoutez un nouveau lecteur ou en supprimez un, mais en l'absence de changement matériel, ils étaient statiques.

Vous pouvez mettre /dev/hda1votre /etc/fstabet être sûr qu'il continuera à fonctionner, au moins en l'absence de changements matériels.

IDE fonctionnait comme ça. Rien après ça.

SATA semble être simple: un port, un disque. Mais non; il permet des multiplicateurs de ports. Et il permet le remplacement à chaud. Pourtant, en l'absence de modifications matérielles, vous pouvez toujours continuer à faire fonctionner le mappage.

L'USB est bien pire. Non seulement il permet le remplacement à chaud, mais il est typique. Les gens branchent des clés USB à tout moment. De plus, les appareils peuvent prendre un certain temps à sonder - et peuvent en fait changer quand ils en ont envie (par exemple, lorsque vous activez ou désactivez le mode de stockage USB sur votre téléphone). Firewire est similaire. Dans les deux cas, vous ne pouvez pas vraiment trouver une cartographie stable.

Les disques connectés au réseau n'ont aucun ordre de port inhérent. Le seul ordre utilisé par le noyau est l'ordre dans lequel il est apparu. Idem pour les volumes logiques.

La quête de la vitesse de démarrage a également aggravé les choses. À l'origine, le noyau se contentait de rester assis et d'attendre assez longtemps, par exemple, tous les périphériques USB pour s'initialiser. Pour sonder complètement tous les bus SCSI, etc. Ces sondes ont été transformées en tâches d'arrière-plan; boot ne les attendrait plus. Les appareils sont ajoutés à mesure que les sondes sont terminées.

Ainsi, le noyau a été laissé avec, plus ou moins, "quel que soit l'ordre dans lequel ils apparaissent". Cela signifiait que de nombreux types de périphériques pouvaient changer et changeaient d'ordre à chaque démarrage - ce qui était sur un démarrage /dev/sdbétait sur un autre démarrage /dev/sdc. Cela fait de l'idée d'une statique /devune plaisanterie.

Sommaire

Lorsque vous considérez que la combinaison de l'électricité statique /devdevient de plus en plus insignifiante en raison d'ordres de sonde de périphérique imprévisibles et que vous continuez à allouer des nombres majeurs / mineurs statiques conduisant à un travail important pour ne pas s'épuiser, il devient clair pourquoi les développeurs de Linux ont choisi de passer à une dynamique /dev.

Bonne question.

D'une certaine manière, cet argument pourrait être inversé: depuis que le noyau 2.6.13 a introduit une nouvelle version de uevent, il devait se produire qu'il devfsfaudrait réécrire pour tirer parti des nouvelles fonctionnalités de l'interface. Donc, d'une certaine manière, la question devrait être de savoir pourquoi le changement dans le noyau.

Cependant, en le prenant à sa valeur nominale, votre question est répondue dans cet article de Wikipedia :

Contrairement aux systèmes Unix traditionnels, où les nœuds de périphériques dans le répertoire / dev ont été un ensemble statique de fichiers, le gestionnaire de périphériques Linux udev ne fournit dynamiquement que les nœuds des périphériques réellement présents sur un système. Bien que devfs fournisse des fonctionnalités similaires, Greg Kroah-Hartman a cité un certain nombre de raisons pour préférer son implémentation à devfs:

1) udev prend en charge la dénomination persistante des périphériques, qui ne dépend pas, par exemple, de l'ordre dans lequel les périphériques sont connectés au système. La configuration par défaut d'udev fournit des noms persistants pour les périphériques de stockage. Tout disque dur est reconnu par son identifiant de système de fichiers unique, le nom du disque et l'emplacement physique sur le matériel auquel il est connecté.

2) udev s'exécute entièrement dans l'espace utilisateur, contrairement à l'espace noyau de devfs. Une conséquence est que udev a déplacé la politique de nommage hors du noyau et peut exécuter des programmes arbitraires pour composer un nom pour le périphérique à partir des propriétés du périphérique, avant la création du nœud; là, l'ensemble du processus est également interruptible et il fonctionne avec une priorité plus faible.

Je devrais probablement ajouter qu'avec udev, la possibilité d'un race condition, qui a fondamentalement miné le nommage des périphériques dans devfs et hotplug, est évitée. En d'autres termes: avec devfs, il n'y avait aucun moyen de garantir que votre port Ethernet le plus à gauche serait appelé eth0et son port le plus à droite eth1, rendant (à titre d'exemple pur) la configuration de routeurs (un port vers WAN, un port vers LAN) difficile à mettre en place.

L'adoption du schéma de nommage des disques basé sur le GUID est un autre avantage, et le déplacement de l'ensemble du processus vers l'espace utilisateur est encore plus important: avez-vous cherché sur ce site pour voir combien de personnes écrivent leurs propres règles udev?

Comme exemple simple des avantages inhérents à la présence d'udev dans l'espace utilisateur, cochez cette question ou cette autre question , toutes deux sur ce même site.