Para el caso, ¿qué estaba mal exactamente con un montón de archivos estáticos /dev? Aparentemente, no es lo suficientemente satisfactorio para los desarrolladores haber reinventado esta rueda en mi recuento 3 veces ahora ( devfs-> udev + HAL-> udev), y ahora aparentemente también está entrando en el Gran Programa de Iniciación Unificada, así que cuatro veces.

Recuerdo cuando comencé a usar Linux hace años, sorprendiéndome de que a pesar de las afirmaciones de que "todo es un archivo", no existe /dev/eth0(eso luego tuvo sentido, ya que no es un dispositivo de bloque o char, aunque es un tipo de dispositivo "paquete" Sería interesante ...). Dado eso, ¿por qué el programa que maneja el árbol de archivos del dispositivo de bloqueo y char también es responsable de los dispositivos de red? He visto vagas referencias a la "flexibilidad", pero ¿qué agrega esto a lo que, por ejemplo, ifconfig (8) hace con solo mirar /proc/net/dev? Sé, por ejemplo, que NetworkManager no estará en Net o OpenBSD en el corto plazo porque depende de lo udevque ninguno de los equipos quiera escribir; lo que no hago/devque ya están expuestos de múltiples maneras por el núcleo (¡y ninguno de ellos está incluido /dev!).

¿Es solo por la conexión en caliente? ¿Hubo problemas con el kernel simplemente escuchando los buses físicos y cargando los módulos apropiados en un mensaje de "dispositivo agregado"? O, Dios no lo quiera, ¿el administrador real lo hace? Recuerdo que a principios de la década de 2000, mis servidores a veces inicializaban sus tarjetas de red en un orden inesperado, y supongo que tiene sentido que ese nombre se decida en el país de usuario (aunque no fue terriblemente difícil de arreglar en ese momento), pero Esto parece un mazo para una cucaracha. (O tal vez ese problema afecta a casos de uso en los que no estoy pensando mucho más que los servidores o PC montados en bastidor, que es mi experiencia).

Entonces, para expresar mi pregunta con claridad: ¿qué problemas resuelve realmente udev, y cómo no pudieron resolverlos devfs, HAL y / o un archivo antiguo simple? ¿Existe una razón particular para que tantas cosas diferentes (conexión en caliente, administración general de dispositivos, administración de dispositivos de red, nombres de dispositivos, prioridad de controladores, etc.) sean un solo programa?

Dos cosas más: el paso de Linux a la empresa y otros servidores grandes estaba exponiendo la electricidad estática /dev. La tecnología avanzada, tanto en el consumidor como en la empresa, estaba exponiendo static / dev como una broma. [Esta respuesta llena más de la historia de fondo, no particularmente por qué devfs fue reemplazado por udev].

Agotamiento del espacio numérico mayor y menor

/devlos archivos se identifican dentro del núcleo por sus números mayores y menores. El núcleo nunca se ha preocupado por el nombre (y usted podría, por ejemplo, mv /dev/sda /dev/disk-1y continuaría funcionando, aunque, por supuesto, los programas no sabrían dónde encontrarlo).

Con una estática /dev, debe asignar un número mayor / menor para cada dispositivo potencial que pueda existir. Estos números deben ser únicos a nivel mundial, ya que se envían como parte de distribuciones, no creados a pedido. El problema es que cada uno de ellos es un número de 8 bits, el rango es 0-255.

Originalmente, por ejemplo, Linux comenzó con 8,0 siendo sda, 8,1 siendo sda1, 8,16 siendo sdb, etc. Pero la gente seguía agregando más y más discos a las máquinas, especialmente cuando consideraba cosas como el canal de fibra. Entonces, en algún momento, se agregaron los números principales 65-71 para más discos. Más tarde, los principales números 128-135. Y sin embargo, la gente seguía queriendo más discos ...

Y surgieron formatos de tabla de particiones como GPT, que admiten más particiones por disco. Y, por supuesto, otros dispositivos estaban consumiendo el espacio numérico: varios controladores RAID, gestión lógica de volumen, etc.

El resultado final se puede ver en la lista de dispositivos LANANA Linux . Si observa la lista 2.6 (la única que sigue allí), se utilizan muchos de los números principales de bloque hasta 200 (máx .: 255). Claramente, los números se habrían agotado.

Cambiar a números más grandes no fue fácil. Cambia el núcleo ABI. Dependiendo del sistema de archivos, cambia el diseño en disco. Pero, por supuesto, la mayoría de esos dispositivos no existían en ningún sistema, incluso uno que (por ejemplo) se estaba quedando sin discos SCSI probablemente tenía muchas cosas libres, probablemente no necesitaba un disco duro IBM XT, por ejemplo.

Con una dinámica /dev, la distribución no tiene que enviar los números de dispositivo. Ya no tienen que ser globalmente únicos. Ni siquiera tienen que ser únicos en las botas.

Los nombres de los dispositivos eran impredecibles.

Solía ​​ser muy fácil asignar un número a todo. Una placa tenía dos canales IDE; cada canal IDE soportaba un maestro y un esclavo. Puede asignar en orden de canal y orden maestro-luego-esclavo. Entonces se hdaconvierte en el primer canal, maestro; hdbprimer canal, esclavo; hdcsegundo canal, maestro; etc. Eran predecibles y estables. Pueden cambiar si agrega una nueva unidad o quita una, pero a falta de un cambio de hardware, eran estáticos.

Puede poner /dev/hda1su /etc/fstaby estar seguro de que seguirá funcionando, al menos sin cambios de hardware.

IDE funcionó así. Nada después de eso.

SATA parece ser simple: un puerto, un disco. Pero no es así; Permite multiplicadores de puertos. Y permite el intercambio en caliente. Aún así, a falta de cambios de hardware, aún puede mantener el mapeo funcionando.

El USB es mucho peor. No solo permite el intercambio en caliente, es típico. Las personas conectan unidades flash USB todo el tiempo. Además, los dispositivos pueden tardar un tiempo en sondear, y en realidad pueden cambiar cada vez que lo deseen (por ejemplo, al encender o apagar el modo de almacenamiento USB en su teléfono). Firewire es similar. Con ninguno de los dos puede realmente llegar a un mapeo estable.

Los discos conectados a la red no tienen ningún orden de puertos inherente. El único orden que utiliza el núcleo es el orden en que aparecieron. Lo mismo ocurre con los volúmenes lógicos.

La búsqueda de la velocidad de arranque también empeoró las cosas. Originalmente, el núcleo se sentaría felizmente y esperaría un tiempo bastante largo para, por ejemplo, que todos los dispositivos USB se inicialicen. Para sondear completamente todos los buses SCSI, etc. Esas sondas se convirtieron en tareas en segundo plano; la bota ya no los esperaría. Los dispositivos se agregan a medida que se completan las sondas.

Así que el núcleo se quedó con, más o menos, "cualquier orden en que aparezcan". Esto significaba que muchos tipos de dispositivos pueden cambiar y cambiaron el orden de cada arranque; lo que estaba en un arranque /dev/sdbestaba en otro arranque /dev/sdc. Esto hace que la idea de una estática sea /devuna broma.

Resumen

Cuando toma la combinación de estática /devcada vez más sin sentido debido a órdenes de sondeo de dispositivos impredecibles, y continúa asignando números mayores / menores estáticos que conducen a un trabajo sustancial para que no se agote, queda claro por qué los desarrolladores de Linux eligieron cambiar a una dinámica /dev.

Buena pregunta.

En cierto modo, este argumento podría revertirse: dado que el kernel 2.6.13 introdujo una nueva versión de uevent, es probable que devfsdeba reescribirse para aprovechar las nuevas características de la interfaz. Entonces, en cierto modo, la pregunta debería ser por qué el cambio en el núcleo.

Sin embargo, tomándolo al pie de la letra, su pregunta se responde en este artículo de Wikipedia :

A diferencia de los sistemas Unix tradicionales, donde los nodos de dispositivos en el directorio / dev han sido un conjunto estático de archivos, el administrador de dispositivos udev de Linux proporciona dinámicamente solo los nodos para los dispositivos realmente presentes en un sistema. Aunque los devfs solían proporcionar una funcionalidad similar, Greg Kroah-Hartman citó una serie de razones para preferir su implementación sobre los devfs:

1) udev admite nombres de dispositivos persistentes, lo que no depende, por ejemplo, del orden en que los dispositivos están conectados al sistema. La configuración predeterminada de udev proporciona nombres persistentes para dispositivos de almacenamiento. Cualquier disco duro es reconocido por su identificación única del sistema de archivos, el nombre del disco y la ubicación física en el hardware al que está conectado.

2) udev se ejecuta completamente en el espacio del usuario, a diferencia del espacio del kernel de devfs. Una consecuencia es que udev retiró la política de nombres del núcleo y puede ejecutar programas arbitrarios para componer un nombre para el dispositivo a partir de las propiedades del dispositivo, antes de que se cree el nodo; allí, todo el proceso también es interrumpible y se ejecuta con una prioridad más baja.

Probablemente debería agregar que con udev race conditionse evita la posibilidad de un , que básicamente socavaba la denominación de dispositivos en devfs y hotplug. En otras palabras: con devfs no había forma de garantizar que se llamara a eth0su puerto ethernet más a la izquierda y que fuera el más a la derecha eth1, lo que dificultaba (como ejemplo puro) la configuración de enrutadores (un puerto para WAN, un puerto para LAN) implementar.

La adopción del esquema de nomenclatura de los discos basado en GUID es otra ventaja, y mover todo el proceso al espacio de usuario es aún más grande: ¿ha buscado en este sitio para ver cuántas personas escriben sus propias reglas de udev?

Como un ejemplo simple de las ventajas inherentes a tener udev en el espacio de usuario, marque esta pregunta o esta otra pregunta , ambas en este mismo sitio.