El problema que resuelve el device model

Durante los años noventa cada subsistema del kernel llevaba su propia contabilidad de hardware: PCI tenía sus tablas, USB las suyas, SCSI otras. Nadie podía responder a una pregunta tan simple como “quién es el padre de este dispositivo”. Esa pregunta parece académica hasta que intentas suspender un portátil: no puedes apagar el controlador USB antes que el ratón que cuelga de él. El device model, incorporado en la serie 2.6, nació para dar al kernel un único árbol de objetos donde dispositivos, drivers y buses conviven con relaciones explícitas.

El caos anterior: cada subsistema, su universo

Antes del device model cada bus era una isla. El código PCI mantenía sus propias listas de pci_dev, el código USB las suyas de usb_device, y ninguno compartía tipo ni convención con el otro. Enumerar todo el hardware de la máquina significaba recorrer subsistemas incompatibles con recorridos distintos, y no existía ninguna estructura común desde la que preguntar algo genérico.

/* Antes: cada subsistema con su estructura y sus listas propias.
   Ningun tipo comun, ninguna relacion padre-hijo explicita. */
struct pci_dev     *pdev;   /* el mundo PCI, con su tabla de IDs        */
struct usb_device  *udev;   /* el mundo USB, incompatible con el anterior */
struct scsi_device *sdev;   /* el mundo SCSI, otra isla mas             */

/* pregunta imposible de responder de forma generica:
   dado un puntero cualquiera, quien es su dispositivo padre? */

El problema no era estético. Sin un tipo común no había forma de escribir código transversal —gestión de energía, hotplug, exportación a userspace— que funcionara para cualquier dispositivo. Cada nueva necesidad se reimplementaba bus por bus, y las relaciones de dependencia física entre dispositivos vivían solo en la cabeza del programador.

El otro gran empuje fue el hotplug. Un USB que se enchufa diez horas después de arrancar tiene que notificar a userspace para que se cargue su driver y se cree su nodo, y esa notificación necesitaba un formato común: no tenía sentido un mecanismo de aviso distinto por cada bus. Energía y hotplug empujaban en la misma dirección —un árbol único de objetos con nombre, padres y un canal de eventos— y de esa convergencia nació el modelo.

La energía lo cambió todo: hace falta un árbol

El catalizador fue la gestión de energía. Suspender una máquina no es apagar dispositivos en cualquier orden: un dispositivo debe suspenderse antes que aquel del que depende. El ratón USB se suspende antes que el controlador USB, que se suspende antes que el puente PCI que lo alberga. Reanudar exige el orden inverso. Esto solo es expresable si el kernel conoce, para cada dispositivo, quién es su padre.

/* include/linux/device.h (resumido) */
struct device {
	struct kobject		kobj;      /* base comun: nombre, refcount, sysfs */
	struct device		*parent;   /* EL ESLABON QUE FALTABA */
	const struct bus_type	*bus;      /* como esta conectado    */
	struct device_driver	*driver;   /* quien lo gobierna, o NULL */
	dev_t			devt;      /* major:minor para /dev  */
	void	(*release)(struct device *dev);
	/* ...decenas de campos mas... */
};

Con el campo parent el kernel construye un árbol y lo linealiza en una lista de energía. El apagado la recorre en orden inverso al de registro: como el hijo siempre se registra después del padre, ir hacia atrás garantiza suspender las hojas antes que la raíz.

/* drivers/base/power/main.c — idea esencial del apagado ordenado */
void dpm_suspend(pm_message_t state)
{
	struct device *dev;

	/* dpm_list guarda los dispositivos en ORDEN DE REGISTRO; como el
	   hijo se registra despues del padre, recorrerla al reves suspende
	   siempre las hojas antes que la raiz de la que dependen */
	list_for_each_entry_reverse(dev, &dpm_list, power.entry)
		device_suspend(dev);
}

flowchart TD
ROOT[Raiz virtual] --> PCI[Puente PCI]
PCI --> USBC[Controlador USB]
USBC --> HUB[Hub USB]
HUB --> MOUSE[Raton]
HUB --> KBD[Teclado]
MOUSE -. se suspende antes que .-> HUB
HUB -. se suspende antes que .-> USBC

Quién libera el objeto: el conteo de referencias

El segundo problema es la vida del objeto. Un struct device no lo referencia solo su driver: lo apuntan sysfs, el subsistema de energía, un proceso que tiene abierto un fichero en /sys, otro dispositivo hijo. Si el driver hace kfree mientras alguien lo mira, el kernel corrompe memoria. La única solución correcta es contar referencias y liberar solo cuando la cuenta llega a cero.

/* nadie sabe cuantos punteros vivos hay a un device: por eso se cuentan */
struct device *get_device(struct device *dev);  /* +1 a kobj.kref         */
void           put_device(struct device *dev);   /* -1; en 0 llama release */

Por eso struct device no se libera con kfree sino a través de su función release, invocada por el conteo de referencias cuando cae el último usuario. Ese mecanismo no es exclusivo del dispositivo: vive en el kobject que todos ellos incrustan, la pieza que verás en la lección 28.2.

La respuesta: un modelo unificado

La solución fue una tríada de tipos comunes —struct bus_type, struct device_driver y struct device— asentada sobre un ladrillo universal, el kobject, y con una ventana a userspace, sysfs. Cada dispositivo, cada driver y cada bus pasan a ser objetos de primera clase con nombre, lugar en el árbol, conteo de referencias y representación en /sys. La topología deja de vivir en la cabeza del programador y pasa a ser una estructura de datos que el kernel puede recorrer.

Esa estructura se vuelve palpable en /sys, donde el mismo dispositivo aparece a la vez desde tres ejes: su lugar físico en el árbol, su bus y su clase.

# la topologia fisica: sigue los padres hacia la raiz
ls -l /sys/devices/
# el eje de conexion y el eje de funcion, para el mismo hardware
ls /sys/bus/           # pci, usb, i2c, platform...
ls /sys/class/         # net, block, tty, leds...

Esas tres vistas no son tres copias del hardware, sino tres proyecciones del único árbol de objetos que ahora vive en el kernel. Antes no existía ninguna; había islas incomunicadas.