udev (espacio de usuario / dev) es un administrador de dispositivos para el kernel de Linux . Como sucesor de devfsd y hotplug, udev administra principalmente los nodos de dispositivos en el directorio / dev . Al mismo tiempo, udev también maneja todos los eventos de espacio de usuario que surgen cuando los dispositivos de hardware se agregan al sistema o se eliminan de él, incluida la carga de firmware según lo requieran ciertos dispositivos.
Desarrollador (es) | Greg Kroah-Hartman y Kay Sievers |
---|---|
Versión inicial | Noviembre de 2003 |
Lanzamiento estable | 248 (30 de marzo de 2021 [±] [1] | )
Repositorio | |
Escrito en | C |
Sistema operativo | Kernel de Linux |
Tipo | Nodo de dispositivo |
Licencia | GPLv2 |
Sitio web | Página web oficial |
Razón fundamental
Es un sistema operativo 's núcleo que es responsable de proporcionar una interfaz abstracta del hardware para el resto del software. Al ser un kernel monolítico , el kernel de Linux hace exactamente eso, y los controladores de dispositivo son parte del kernel de Linux, que constituye más del 50% 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 tratar con dispositivos periféricos que son compatibles con hotplug de una manera fácil de usar, una parte del manejo de todos estos dispositivos de hardware con capacidad hotplug se transfirió del kernel a un demonio que se ejecuta en el espacio del usuario. La ejecución en el espacio del usuario tiene fines de seguridad y estabilidad.
Diseño
Los controladores de dispositivos son parte del kernel de Linux, en el que sus funciones principales incluyen el descubrimiento de dispositivos, la detección de cambios de estado del dispositivo y funciones similares de hardware de bajo nivel. Después de cargar un controlador de dispositivo en la memoria desde el kernel, los eventos detectados se envían al demonio del espacio de usuario udevd. Es el administrador de dispositivos, udevd , quien captura todos estos eventos y luego decide qué sucederá a continuación. Para esto, udevd tiene un conjunto muy completo de archivos de configuración, que pueden ser ajustados por el administrador de la computadora, de acuerdo con sus necesidades.
- En caso de que se conecte un nuevo dispositivo de almacenamiento a través de USB, udevd es notificado por el kernel y él mismo notifica al udisksd-daemon. Ese demonio podría montar los sistemas de archivos.
- En caso de que se conecte un nuevo cable Ethernet a la NIC Ethernet, udevd es notificado por el kernel y él mismo notifica al NetworkManager-daemon. El NetworkManager-daemon podría iniciar dhclient para esa NIC o configurarlo de acuerdo con alguna configuración manual.
La complejidad de hacerlo obliga a los autores de aplicaciones a volver a implementar la lógica de soporte de hardware. Algunos dispositivos de hardware también requieren programas auxiliares privilegiados para prepararlos para su uso. A menudo, estos deben invocarse de maneras que pueden ser incómodas de expresar con el modelo de permisos de Unix (por ejemplo, permitir que los usuarios se unan a redes inalámbricas solo si están conectados a la consola de video). Los autores de aplicaciones recurren al uso de binarios setuid o ejecutan demonios de servicio para proporcionar su propio control de acceso y separación de privilegios, lo que podría introducir agujeros de seguridad cada vez. [3]
HAL se creó para hacer frente a esto, pero ahora está en desuso en la mayoría de las distribuciones de Linux.
Descripción general
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 nombres de dispositivos persistentes, que no dependen, por ejemplo, del orden en el que se conectan los dispositivos al sistema. La configuración predeterminada de udev proporciona nombres persistentes para los dispositivos de almacenamiento. Cualquier disco duro se reconoce por su identificación única de sistema de archivos, el nombre del disco y la ubicación física en el hardware al que está conectado.
- udev se ejecuta completamente en el espacio del usuario , a diferencia del espacio del kernel de devfs . Una consecuencia es que udev sacó la política de nombres del kernel 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.
El udev, en su conjunto, se divide en tres partes:
- Biblioteca libudev que permite el acceso a la información del dispositivo; se incorporó al paquete de software systemd 183. [5]
- Demonio de espacio de usuarioudevd que gestiona el virtual / dev .
- Utilidad administrativa de línea de comandos udevadm para diagnósticos.
El sistema recibe llamadas del kernel a través del conector netlink . Las versiones anteriores usaban hotplug , agregando un enlace a sí mismas en /etc/hotplug.d/default con este propósito.
Operación
udev es un administrador de dispositivos genéricos se ejecuta como un demonio en un sistema Linux y escuchar (a través de un enlace de red socket) a uevents el núcleo envía si un nuevo dispositivo es inicializado o un dispositivo se retira del sistema. El paquete udev viene con un extenso conjunto de reglas que coinciden con los valores exportados del evento y las propiedades del dispositivo descubierto. Una regla coincidente posiblemente nombrará y creará un nodo de dispositivo y ejecutará programas configurados para instalar y configurar el dispositivo.
Las reglas de udev pueden coincidir en propiedades como el subsistema del kernel, el nombre del dispositivo del kernel, la ubicación física del dispositivo o propiedades como el número de serie del dispositivo. Las reglas también pueden solicitar información de 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 realizaría más acciones específicas del dispositivo. Por ejemplo, HAL notificaría a otro software que se ejecuta en el sistema que el nuevo hardware ha llegado emitiendo un mensaje de difusión en el sistema D-Bus IPC a todos los procesos interesados . De esta manera, los equipos de escritorio como GNOME o K Desktop Environment 3 podrí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 desaprobado 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 previamente incorporada en HAL se ha integrado en el propio udev, o se ha trasladado a un software independiente como udisks y upower .
- udev proporciona acceso de bajo nivel al árbol de dispositivos de Linux. Permite a los programas enumerar dispositivos y sus propiedades y recibir notificaciones cuando los dispositivos entran y salen.
- dbus es un marco que permite que los programas se comuniquen entre sí de forma segura, confiable y con una interfaz de programación orientada a objetos de alto nivel.
- udisks (anteriormente conocido como DeviceKit-disks) es un demonio que se ubica sobre libudev y otras interfaces del kernel y proporciona una interfaz de alto nivel para dispositivos de almacenamiento y es accesible a través de dbus para aplicaciones.
- upower (anteriormente conocido como DeviceKit-power) es un demonio que se ubica sobre libudev y otras interfaces del kernel y proporciona una interfaz de alto nivel para la administración de energía y es accesible a través de dbus para las aplicaciones.
- NetworkManager es un demonio que se encuentra en la parte superior de libudev y otras interfaces del kernel (y un par de otros demonios) y proporciona una interfaz de alto nivel para la configuración y configuración de la red y es accesible a través de dbus a las aplicaciones. [9]
udev recibe mensajes del kernel y los pasa a los demonios del subsistema como Network Manager. Las aplicaciones se comunican con Network Manager a través de D-Bus.
HAL es obsoleto y solo lo usa el código heredado. Ubuntu 10.04 se envía sin HAL. Inicialmente, se planeó un nuevo demonio DeviceKit para reemplazar ciertos aspectos de HAL, pero en marzo de 2009, DeviceKit quedó en desuso a favor de agregar el mismo código a udev como paquete: udev-extras, y algunas funciones ahora se han movido a udev propiamente dicho.
Historia
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 usa una nueva versión de udev no arrancará con kernels anteriores a 2.6.13 a menos que udev esté deshabilitado y se use un directorio / dev tradicional para el acceso al dispositivo.
En abril de 2012, la base de código de udev se fusionó con el árbol de fuentes 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 de firmware , afirmando: [12]
Sí, hacerlo en el kernel es "más robusto". Pero no juegues y deja de mentir. Es más robusto porque tenemos mantenedores que se preocupan y porque sabemos que las regresiones no son algo con lo que podamos jugar rápido y relajado. Si algo se rompe y no sabemos cuál es la solución correcta para esa rotura, revertimos lo que se rompió. Así que sí, claramente es mejor hacerlo en el kernel. No porque la carga de firmware no se pueda realizar en el espacio de usuario. Pero simplemente porque el mantenimiento de udev desde que Greg lo abandonó ha ido cuesta abajo.
En 2012, el proyecto Gentoo Linux creó una bifurcación de la base de código 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 a 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 software existente como OpenRC y Upstart , kernels más antiguos, varias cadenas de herramientas y cualquier otra cosa que requieran los usuarios y diversas distribuciones.
El 29 de mayo de 2014, el soporte para la carga de firmware a través de udev se eliminó de systemd, ya que se decidió que la tarea del kernel era cargar el firmware. [15] Dos días después, Lennart Poettering sugirió posponer este parche hasta que udev comience a utilizar kdbus; en ese momento, el plan era cambiar udev para usar kdbus como el sistema de mensajería subyacente, y deshacerse del transporte basado en netlink de espacio de usuario a espacio de usuario. [dieciséis]
Autores
udev fue desarrollado por Greg Kroah-Hartman y Kay Sievers , con mucha ayuda de Dan Stekloff , entre otros.
Referencias
- ^ Versión v248 , 30 de marzo de 2021 , consultado el 2 de abril de 2021
- ^ Martí, Don. "¿Los principales desarrolladores de Linux están perdiendo la voluntad de codificar?" . ComputerworldUK . Consultado el 19 de junio de 2016 .
- ^ Pennington, Havoc (10 de julio de 2003), Making Hardware Just Work
- ^ Greg Kroah-Hartman . "udev y devfs - La última palabra" . Archivado desde el original ( texto sin formato ) el 2011-07-09 . Consultado el 24 de enero de 2008 .
- ^ a b c "systemd / systemd" . GitHub . Consultado el 21 de agosto de 2016 .
- ^ "Gestión dinámica de dispositivos en Udev" (PDF) . Revista Linux. 2006-10-01 . Consultado el 14 de julio de 2008 .
- ^ "HALRemoval" . 2011-06-28 . Consultado el 13 de septiembre de 2011 .
- ^ "Thunar-volman y la desaprobación de HAL en Xfce" . 2010-01-17 . Consultado el 25 de diciembre de 2017 .
- ^ Lennart Poettering (25 de abril de 2010). "¿Relación entre udev, hal, Dbus y DeviceKit?" .
- ^ Sievers, Kay (3 de abril de 2012). "El futuro del árbol de fuentes de udev" . linux-hotplug (lista de correo) . Consultado el 22 de mayo de 2013 .
- ^ Sievers, Kay, "Commit importing udev into systemd" , systemd , consultado el 22 de mayo de 2013
- ^ Linus Torvalds (3 de octubre de 2012). "Re: roturas de udev" . linux-kernel (lista de correo) . Consultado el 28 de octubre de 2014 .
- ^ "gentoo / eudev - README.md" . Consultado el 25 de diciembre de 2017 .
- ^ "Proyectos Gentoo Linux - Proyecto Gentoo eudev" . Consultado el 25 de diciembre de 2017 .
- ^ "[systemd-devel] [PATCH] Suelta el cargador de firmware udev" . 2014-05-29.
- ^ "[systemd-devel] [PATCH] Suelta el cargador de firmware udev" . 2014-05-31.
enlaces externos
- Página web oficial