☰

¿Existen alternativas al uso de `udev`?

tag-icon • tag-icon linux devices udev
¿Existen alternativas al uso de `udev`?

Si bien entiendo la grandeza de udev y aprecio el esfuerzo de los desarrolladores, simplemente me preguntaba si existe una alternativa.

Por ejemplo, podría imaginar que debería haber una manera de crear un script de inicio que cree la mayoría de los nodos de dispositivos que en mi sistema (sin cambiar el hardware) son casi iguales de todos modos.

El beneficio o la razón por la que me gustaría omitir udevsería el mismo que para omitir dbus, es decir, reducir la complejidad y, por lo tanto, aumentar mis cambios para configurar el sistema de manera más segura.

Respuesta1

Los kernels de Linux modernos admiten el devtmpfssistema de archivos (no lo confunda con el antiguo devfs) , que crea todos los nodos de dispositivos dinámicamente tan pronto como el kernel los descubre. (De hecho, los últimos udevlanzamientosrequerireste; encontrará que udev ya no crea ningún nodo de dispositivo, solo enlaces simbólicos).

De manera similar, la carga del firmware también se ha movido al kernel, por lo que las únicas tareas restantes que udevse realizan son la carga del módulo (de acuerdo con las modalidades) y la aplicación de permisos del dispositivo y otras reglas de udev.

Entonces, en teoría, un núcleo completamente monolítico deberíabotaestá bien sin udev.

Sin embargo, el verdadero problema aquí es lo que sucede después.

  1. Muchos programas de espacio de usuario dependen de que udev mantenga la base de datos de su dispositivo, a la que se puede acceder a través de libudev. Si bien enumerar dispositivos y escuchar eventos agregados/eliminados se puede hacer directamente usando las interfaces del kernel (sysfs y netlink), aún se quedará sin todos los metadatos que varias reglas de udev han adjuntado.

  2. Las reglas de udev también mantienen varios enlaces simbólicos "persistentes" en /dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-pathetc. Por ejemplo, si tiene dos discos conectados, no hay garantía de que el primero siempre sea sdao sdb, pero udev garantiza que los enlaces simbólicos /dev/disk/by-uuidcontinuarán apuntando al correcto.

  3. Si bien los nodos de dispositivo ahora son creados por el kernel y, por lo tanto, ya no son de su incumbencia, aún es importante tener en cuenta que algunos tipos de dispositivos han comenzado a usar números mayores/menores asignados dinámicamente, por lo que aunque hoy tenga /dev/fuse10,228 y /dev/hpet10,229,voluntadtienen números diferentes después de cada reinicio, por lo que devtmpfso (en sistemas más antiguos) un programa que escucha uevents esrequerido.

Muchas de estas cosas podrían hacerse fácilmente con otros programas como mdev, por supuesto. Mi punto es que un /etc/MAKEDEVscript estático ya no funcionará...

Entonces, básicamente, cuando se trata de complejidad de arranque, es muy probable que udev sea elel menosde sus inquietudes.

Respuesta2

Existen varias alternativas udev. Aparentemente Gentoo puede usar algo llamadomdev. Otra opción sería intentar utilizar udevel predecesor devfsd. Finalmente, siempre puedes crear todos los archivos de dispositivo que necesites con mknod.

Tenga en cuenta que con esta última no es necesario crear todo en el momento del arranque, ya que los nodos se pueden crear en el disco y no en un sistema de archivos temporal como ocurre con las otras opciones. Por supuesto, se pierde la flexibilidad de tener archivos de dispositivo creados dinámicamente cuando se conecta nuevo hardware (por ejemplo, una memoria USB). Creo que el enfoque estándar en esta era era tener creados todos los archivos de dispositivo que razonablemente pudiera necesitar /dev(es decir, muchos archivos de dispositivo).

Por supuesto, la dificultad para lograr que cualquiera de estos enfoques funcione en una distribución moderna probablemente sea bastante alta. La wiki de Gentoo menciona dificultades para mdevtrabajar con un entorno de escritorio (y mucho menos fuera de Gentoo). La última devfsdversión fue 2002, no tengo idea si funcionará con kernels modernos. Crear los nodos manualmente es probablemente el enfoque más viable, pero incluso deshabilitarlos udevpodría ser un desafío, particularmente en el uso de distos systemd( udevahora es parte de systemd, lo que sugiere una fuerte dependencia).

Mi consejo es seguir adelante udev;)

Respuesta3

Hay varias alternativas:

  • Simplemente tenga un conjunto de comandos apropiados chmod, chown, lny similares en un script que se ejecute como parte del programa de arranque.
  • Utilice systemd-udev, el administrador plug-and-play que forma parte del proyecto systemd.
  • UsarGentooeudev, que es una bifurcación de systemd-udevla cual systemd ahora se ha diferenciado significativamente.
  • UsarDevuanvdev, que es un administrador plug-and-play desarrollado por Jude Nelson, que forma parte de Devuan.
  • Use mdev, que al contrario de otra respuesta no es cosa de Gentoo. Es el administrador plug-and-play integrado enCaja ocupada.
  • Usarsin mamarmdevque es un administrador plug-and-play desarrollado por Dimitris Papastamos.
  • UsarLaurent Bercotmdevd, cuya configuración es compatible con la de BusyBox mdevpero realiza su propio manejo de sockets y no comprende el protocolo LISTEN.

Todos estos, aparte del primero, requieren conjuntos de reglas que describan cómo reaccionar ante los eventos de notificación del kernel sobre los dispositivos. Obviamente.

También hay herramientas que tomarán programas diseñados para /proc/sys/kernel/hotplug, como los dos mdevs, y que los adaptarán y serializarán escuchando un socket netlink y luego generando esos programas:

Respuesta4

Esto es antiguo, pero quiero capturar mi solución aquí para cualquiera que busque en vano.
No es fácil evitar udev. Dejar DEVTMPFS fuera de la configuración no impide que el kernel monte un disco RAM en /dev y lo complete. Desafortunadamente, no crea los puntos de montaje /dev/shm y /dev/pts necesarios. Lo que es necesario es agregar devtmpfs.mount=0 a los argumentos de arranque.

información relacionada