¿Existen alternativas al uso de `udev`?

Hay varias alternativas a udev allí afuera. Aparentemente Gentoo puede usar algo llamado mdev . Otra opción sería intentar usar udev predecesor de devfsd . Finalmente, siempre puedes crear todos los archivos de dispositivo que necesites con mknod .

Tenga en cuenta que con este último 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 con las otras opciones. Por supuesto, pierde la flexibilidad de tener archivos de dispositivo creados dinámicamente cuando se conecta un nuevo hardware (por ejemplo, una memoria USB). Creo que el enfoque estándar en esta era era tener todos los archivos de dispositivos que pudieras necesitar razonablemente ya creados en /dev (es decir, muchos archivos de dispositivo).

Por supuesto, la dificultad para lograr que cualquiera de estos enfoques funcione en una distribución moderna es probablemente bastante alta. El wiki de Gentoo menciona dificultades para obtener mdev para trabajar con un entorno de escritorio (y mucho menos fuera de Gentoo). El último devfsd El lanzamiento fue en 2002, no tengo ni idea de si funcionará con kernels modernos. Crear los nodos manualmente es probablemente el enfoque más viable, pero incluso deshabilitar udev podría ser un desafío, particularmente en distos que usan systemd (udev ahora es parte de systemd , lo que sugiere una fuerte dependencia).

Mi consejo es seguir con udev;)

Los kernels de Linux modernos admiten el devtmpfs sistema de archivos, que crea todos los nodos del dispositivo de forma dinámica tan pronto como el kernel los descubre. (De hecho, el último udev las versiones requieren este; encontrará que udev ya no crea ningún nodo de dispositivo, solo enlaces simbólicos).

Del mismo modo, la carga del firmware también se ha trasladado al núcleo, por lo que las únicas tareas restantes udev realiza la carga de módulos (según las modalidades) y la aplicación de permisos de dispositivos y otras reglas de udev.

Entonces, en teoría, un kernel completamente monolítico debería arrancar muy bien sin udev.

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

1. Bastantes programas de espacio de usuario dependen de que udev mantenga su base de datos de dispositivos, accesible a través de libudev . Si bien la enumeración de dispositivos y la escucha de eventos agregados/eliminados se pueden realizar directamente mediante 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-path , y así. Por ejemplo, si tiene dos discos conectados, no hay garantía de que el primero siempre sea sda o sdb , pero udev asegura que los enlaces simbólicos en /dev/disk/by-uuid seguirá apuntando a la correcta.

3. Si bien el núcleo ahora crea los nodos de dispositivos y, por lo tanto, ya no es su preocupación, 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 tenga /dev/fuse como 10228 y /dev/hpet como 10,229 hoy, ellos lo harán tienen números diferentes después de cada reinicio, así que devtmpfs o (en sistemas más antiguos) se requiere un programa que escuche uevents .

Muchas de estas cosas se pueden hacer fácilmente con otros programas como mdev , por supuesto. Mi punto es que un /etc/MAKEDEV estático el script ya no va a funcionar...

Entonces, básicamente, cuando se trata de la complejidad de arranque, udev es probablemente el menos de sus preocupaciones.

Hay varias alternativas:

• Simplemente tenga un conjunto de chmod apropiados , chown , ln y comandos similares en un script que se ejecuta como parte del programa de arranque.
• Utilice systemd-udev , el administrador plug-and-play que forma parte del proyecto systemd.
• Usar el eudev de Gentoo , que es una bifurcación de systemd-udev del cual systemd ahora se ha desviado significativamente.
• Usar el vdev de Devuan , que es un administrador plug-and-play desarrollado por Jude Nelson, que es parte de Devuan.
• Usar mdev , que contrariamente a otra respuesta no es una cosa de Gentoo. Es el administrador plug-and-play integrado en BusyBox.
• Usar mdev sin succión que es un administrador plug-and-play desarrollado por Dimitris Papastamos.
• Usar el mdevd de Laurent Bercot , cuya configuración es compatible con mdev de BusyBox pero maneja su propio socket y no entiende el protocolo LISTEN.

Todos estos, además del primero, requieren conjuntos de reglas que describen 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 mdev s, y eso los adaptará y serializará al escuchar un socket de enlace de red y luego generar esos programas:

• El viejo s6-netlink-listener de Laurent Bercot y s6-uevent-spawner
• netlink-datagram-socket-listen y plug-and-play-event-handler del conjunto de herramientas nosh