udev

udev ( userspace /dev ) es un gestor de dispositivos y un conjunto de API para el kernel de Linux . Como sucesor de devfsd y hotplug, udev gestiona principalmente los nodos de dispositivos en el directorio /dev . Asimismo, udev gestiona todos los eventos del espacio de usuario que se producen al añadir o eliminar dispositivos de hardware del sistema, incluyendo la carga del firmware según lo requieran ciertos dispositivos. udev fue desarrollado por Greg Kroah-Hartman y Kay Sievers , con la valiosa colaboración de Dan Stekloff , entre otros.

El núcleo de un sistema operativo es responsable de proporcionar una interfaz abstracta del hardware al resto del software. Al ser un núcleo monolítico , el núcleo de Linux incorpora controladores de dispositivos que representan más de la mitad de su código fuente. ^{[ 2 ]} Se puede acceder al hardware a través de llamadas al sistema o a través de sus nodos de dispositivo .

Para poder gestionar los dispositivos periféricos con capacidad de conexión en caliente de forma sencilla para el usuario, parte de la responsabilidad de gestionar estos dispositivos se delegó del kernel a un demonio que se ejecuta en el espacio de usuario. La ejecución en el espacio de usuario tiene como objetivo garantizar la seguridad y la estabilidad.

Los controladores de dispositivos forman parte del núcleo de Linux, donde sus funciones principales incluyen la detección de dispositivos, la identificación de cambios de estado y otras funciones de hardware de bajo nivel. Tras cargar un controlador de dispositivo en la memoria desde el núcleo, los eventos detectados se envían al demonio udevd del espacio de usuario. Es el gestor de dispositivos, udevd , quien recibe todos estos eventos y decide qué sucederá a continuación. Para ello, udevd cuenta con un conjunto muy completo de archivos de configuración, que el administrador del equipo puede ajustar según sus necesidades.

• En caso de que se conecte un nuevo dispositivo de almacenamiento a través de USB, el kernel notifica a udevd , quien a su vez notifica al demonio udisksd. Este último puede entonces montar los sistemas de archivos.
• Si se conecta un nuevo cable Ethernet a la tarjeta de red Ethernet, el kernel notifica a udevd , quien a su vez notifica al demonio NetworkManager. El demonio NetworkManager puede iniciar dhclient para esa tarjeta de red o configurarla según alguna configuración manual.

La complejidad de hacerlo obligó a los desarrolladores de aplicaciones a reimplementar la lógica de soporte de hardware. Algunos dispositivos de hardware también requerían programas auxiliares con privilegios para prepararlos para su uso. Estos a menudo debían invocarse de maneras que podían ser difíciles de expresar con el modelo de permisos de Unix (por ejemplo, permitir que los usuarios se unieran a redes inalámbricas solo si habían iniciado sesión en la consola de vídeo). Los desarrolladores de aplicaciones recurrieron al uso de binarios setuid o a la ejecución de demonios de servicio para proporcionar su propio control de acceso y separación de privilegios, lo que potencialmente introducía vulnerabilidades de seguridad en cada caso. ^{[ 3 ]}

HAL se creó para hacer frente a estos desafíos, pero ahora está obsoleto en la mayoría de las distribuciones de Linux, y su funcionalidad ha sido reemplazada por udevd.

A diferencia de los sistemas Unix tradicionales , donde los nodos de dispositivo 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 devfs solía proporcionar una funcionalidad similar, Greg Kroah-Hartman citó varias razones ^{[ 4 ]} para preferir udev sobre devfs:

• udev admite la asignación persistente de nombres a los dispositivos, independientemente del orden en que se conecten al sistema. La configuración predeterminada de udev proporciona nombres persistentes para los dispositivos de almacenamiento. Cada disco duro se reconoce por su identificador único del sistema de archivos, su nombre y su ubicación física en el hardware al que está conectado.
• udev se ejecuta completamente en el espacio de usuario , a diferencia de devfs, que se ejecuta en el espacio del kernel . Una consecuencia es que udev trasladó la política de nomenclatura fuera del kernel y puede ejecutar programas arbitrarios para componer un nombre para el dispositivo a partir de sus propiedades, antes de que se cree el nodo; en ese caso, todo el proceso también es interrumpible y se ejecuta con una prioridad menor.

El udev, en su conjunto, se divide en tres partes:

• La biblioteca libudev permite el acceso a la información del dispositivo; se incorporó al paquete de software systemd 183. ^{[ 5 ]}
• Demonio de espacio de usuario udevd que gestiona el /dev virtual .
• Utilidad administrativa de línea de comandos udevadm para diagnóstico.

El sistema recibe llamadas del kernel a través de un socket netlink . Las versiones anteriores utilizaban hotplug , añadiendo un enlace a sí mismas en /etc/hotplug.d/default con este propósito.

udev es un gestor de dispositivos genérico que se ejecuta como un demonio en un sistema Linux y escucha (a través de un socket netlink ) los eventos uevent que el kernel envía cuando se inicializa un nuevo dispositivo o se elimina uno del sistema. El paquete udev incluye un amplio conjunto de reglas que comparan los valores exportados del evento con las propiedades del dispositivo detectado. Una regla coincidente puede asignar un nombre y crear un nodo de dispositivo, y ejecutar programas configurados para configurarlo.

Las reglas de udev pueden coincidir con propiedades como el subsistema del kernel, el nombre del dispositivo del kernel, la ubicación física del dispositivo o propiedades como su número de serie. Las reglas también pueden solicitar información a programas externos para nombrar un dispositivo o especificar un nombre personalizado que siempre será el mismo, independientemente del orden en que el sistema detecte los dispositivos.

En el pasado, una forma común de usar udev en sistemas Linux era permitirle enviar eventos a través de un socket a HAL , que luego realizaba acciones específicas del dispositivo. Por ejemplo, HAL notificaba a otros programas que se ejecutaban en el sistema que el nuevo hardware había llegado, emitiendo un mensaje de difusión en el sistema D-Bus IPC a todos los procesos interesados . De esta manera, entornos de escritorio como GNOME o K Desktop Environment 3 podían iniciar el explorador de archivos para explorar los sistemas de archivos de las unidades flash USB y tarjetas SD recién conectadas . ^{[ 6 ]}

A mediados de 2011, HAL había sido descontinuado por la mayoría de las distribuciones de Linux, así como por los entornos de escritorio KDE, GNOME ^{[ 7 ]} y Xfce ^{[ 8 ]} , entre otros. La funcionalidad que antes estaba incorporada en HAL se ha integrado en el propio udev, o se ha trasladado a software independiente como udisks y upower .

• udev proporciona acceso de bajo nivel al árbol de dispositivos de Linux. Permite a los programas enumerar los dispositivos y sus propiedades, y recibir notificaciones cuando los dispositivos aparecen o desaparecen.
• dbus es un marco de trabajo que permite que los programas se comuniquen entre sí de forma segura, fiable y mediante una interfaz de programación orientada a objetos de alto nivel.
• udisks (anteriormente conocido como DeviceKit-disks) es un demonio que se ejecuta sobre libudev y otras interfaces del kernel, proporcionando una interfaz de alto nivel para los dispositivos de almacenamiento y siendo accesible a través de dbus para las aplicaciones.
• upower (anteriormente conocido como DeviceKit-power) es un demonio que se ejecuta sobre libudev y otras interfaces del kernel, proporcionando una interfaz de alto nivel para la gestión de energía y siendo accesible a través de dbus para las aplicaciones.
• NetworkManager es un demonio que se sitúa sobre libudev y otras interfaces del kernel (y un par de demonios más) y proporciona una interfaz de alto nivel para la configuración y el establecimiento de la red, y es accesible a través de dbus para las aplicaciones. ^{[ 9 ]}

udev recibe mensajes del kernel y los transmite a demonios de subsistemas como Network Manager. Las aplicaciones se comunican con Network Manager a través de D-Bus.

${\displaystyle {\ce {Núcleo -> udev -> Administrador de red <=> D-Bus <=> Firefox}}}$

HAL está obsoleto y solo lo utiliza código heredado. Ubuntu 10.04 se lanzó sin HAL. Inicialmente, se planeó un nuevo demonio, DeviceKit, para reemplazar ciertos aspectos de HAL, pero en marzo de 2009, DeviceKit quedó obsoleto y se optó por añadir el mismo código a udev como paquete: udev-extras. Algunas funciones ahora se han integrado en udev propiamente dicho.

udev se introdujo en Linux 2.5 . La versión 2.6.13 del kernel de Linux introdujo o actualizó una nueva versión de la interfaz uevent . Un sistema que utilice una versión reciente de udev no arrancará con kernels anteriores a la versión 2.6.13 a menos que se desactive udev y se utilice un directorio /dev tradicional para el acceso a los dispositivos.

En abril de 2012, el código fuente de udev se fusionó con el árbol de código fuente de systemd , lo que convirtió a systemd 183 en la primera versión en incluir udev. ^{[ 5 ] [ 10 ] [ 11 ]} En octubre de 2012, Linus Torvalds criticó el enfoque de Kay Sievers para el mantenimiento de udev y la corrección de errores relacionados con la carga del firmware , afirmando: ^{[ 12 ]}

Sí, hacerlo en el kernel es "más robusto". Pero no nos engañemos, dejemos de mentir. Es más robusto porque tenemos mantenedores que se preocupan y porque sabemos que no podemos tomar a la ligera las regresiones. Si algo falla y no sabemos cuál es la solución correcta, revertimos el cambio. Así que sí, es evidente que nos conviene más hacerlo en el kernel. No porque la carga del firmware no se pueda realizar en el espacio de usuario, sino simplemente porque el mantenimiento de udev ha empeorado desde que Greg lo dejó.

En 2012, el proyecto Gentoo Linux creó una bifurcación del código fuente de udev de systemd para evitar la dependencia de la arquitectura de systemd. La bifurcación resultante se llama eudev y hace que la funcionalidad de udev esté disponible sin systemd. Un objetivo declarado del proyecto es mantener eudev independiente de cualquier distribución de Linux o sistema de inicio . ^{[ 13 ]} El proyecto Gentoo describe eudev de la siguiente manera: ^{[ 14 ]}

eudev es una bifurcación de systemd-udev con el objetivo de obtener una mejor compatibilidad con el software existente, como OpenRC y Upstart , núcleos antiguos, diversas cadenas de herramientas y cualquier otra cosa que requieran los usuarios y las distintas distribuciones.

El 29 de mayo de 2014, systemd dejó de admitir la carga de firmware a través de udev, ya que se decidió que la carga del firmware es tarea del kernel. ^{[ 15 ]} Dos días después, Lennart Poettering sugirió que este parche se pospusiera hasta que udev comenzara a utilizar kdbus ; en ese momento, el plan era cambiar udev para que utilizara kdbus como sistema de mensajería subyacente y eliminar el transporte basado en netlink de espacio de usuario a espacio de usuario. ^{[ 16 ]}

• Sitio web oficial