En los sistemas operativos modernos, los subsistemas para manejo de dispositivos tienen cada vez más importancia, ya que tienen que enfrentarse a muchísimos buses internos y externos, y no pasa un día sin que aparezcan dispositivos nuevos (y casi fabricantes). Es lógico por tanto que la siguiente actualización del kernel Linux haya mejorado tanto en el cargador de módulos como en la organización interna de la información. Hay desde cambios puramente cosméticos (los módulos de drivers pasan a tener extensión ".ko", por "objeto de kernel" [kernel object], en lugar de la tradicional ".o") hasta una remodelación completa del modelo unificado de dispositivos. En todos ellos se hace especial énfasis en la estabilidad, y se intentan superar las limitaciones encontradas en anteriores versiones.
Dentro del subsistema de módulos, hay unos cuantos cambios para mejorar la estabilidad. El proceso para descargar módulos intenta asegurarse de que no se acceda a un módulo que está siendo desactivado, lo que puede causar cuelgues. También puede deshabilitarse la descarga de módulos en sistemas críticos. Por último, se hace hincapié en la necesidad de que los módulos informen al kernel de qué periféricos soportan. Hasta ahora, el módulo sabía con qué dispositivos puede entenderse, pero esta información no llegaba a salir de ellos. Bajo el nuevo modelo, se hace posible la gestión inteligente de hardware mediante herramientas externas, tales como kudzu de RedHat. Por supuesto, cuando el usuario está seguro de que determinado driver puede ser usado con cierto dispositivo, puede forzar su utilización.
El modelo de dispositivos del nuevo kernel tiene otros cambios aparte de la simple carga de módulos: no se trata sólo de determinar qué módulos van con qué hardware, sino de asumir responsabilidad de todo el hardware en un sistema dado. Hasta la versión 2.2 de Linux, el modelo de dispositivos era el mínimo indispensable: casi toda la responsabilidad dependía de los módulos individuales. Este esquema funcionaba bien, pero para las funcionalidades avanzadas del hardware moderno (especialmente ACPI), no basta con que el sistema controle qué recursos usa cada dispositivo: además tiene que saber a qué bus está conectado, qué sub-dispositivos hay, en qué estado están, si puede reconfigurarse para usar otros recursos en caso de contención, e incluso conocer dispositivos para los que el módulo no se ha cargado todavía. Linux 2.4 avanzó por este camino, al ser la primera versión que unificaba las interfaces de los buses PCI, PC Card, e ISA Plug-and-Play bajo una estructura única con una interfaz común. Linux 2.6, mediante el subsistema de objetos de kernel ("kobject"), pasa a abarcar todos los dispositivos en un sistema. Además dispone de un interfaz centralizado que gestiona detalles como la cuenta de referencias o la gestión de energía, y los expone al espacio de usuario.
Ahora que el kernel dispone de toda esta información sobre el hardware, Linux es capaz de dar soporte a funcionalidades avanzadas (tanto en portátiles como en sistemas de escritorio) que requieren conocimiento detallado del hardware. La aplicación más visible está en la proliferación de aparatos "en caliente" ["hot plug"] como PC Cards, dispositivos USB y Firewire, y PCI en caliente. Es difícil verlo ahora, pero Linux no llegó a hacerlos funcionar bien hasta el kernel 2.2. Hoy día la conexión en caliente se da por supuesta, y es el momento justo para una infraestructura de dispositivos que elimina las diferencias entre un dispositivo en caliente y uno tradicional. Ya que el subsistema del kernel no diferencia explícitamente entre el hardware encontrado en el arranque y el que se descubre después, la infraestructura para conectar nuevos dispositivos se ha simplificado. Una segunda aplicación del nuevo subsistema es el ahorro de energía. El nuevo estándar en gestión de energía desde hace pocos años, llamado ACPI o "Interfaz Avanzado de Configuración y Energía" [Advanced Configuration and Power Interface], empezó a ser utilizado en la versión anterior del kernel. Al contrario que el estándar anterior APM "Gestión Avanzada de Energía" [Advanced Power Management], los sistemas operativos que lo utilizan deben avisar individualmente a cada dispositivo compatible del cambio en el modo de energía. Está claro que, sin un conocimiento completo del hardware instalado, es imposible que el kernel sepa a qué dispositivos avisar y en qué orden. Aparte de estos dos ejemplos, hay aplicaciones menos obvias en otras áreas, como auditoría y monitorización de hardware, que se beneficiarán del nuevo modelo centralizado.
La última ramificación de la infraestructura centralizada, y la que será más visible al exterior, es el nuevo sistema de archivo del kernel llamado 'sysfs', que viene a hacer compañía a 'proc' para procesos, 'devfs' para dispositivos, y 'devpts' para pseudo-terminales UNIX98. Este sistema de archivos, montado por defecto en '/sys', es una representación estructurada del árbol de dispositivos tal y como lo ve el kernel (con excepciones). Incluye unos cuantos atributos de los dispositivos detectados: nombre del dispositivo, recursos IRQ y DMA, modo de energía, y demás. Un aspecto que puede ser confuso al principio es que la información referente a dispositivos actualmente en el directorio '/proc/sys' acabará probablemente en el nuevo sistema de archivo. Este cambio no se ha completado (todavía), así que estamos seguramente en una fase de transición.
