Re: ¿Donde están mis dispositivos?
El Jueves, 10 de Noviembre de 2005 19:25, Luis Rodrigo Gallardo Cruz escribió:
|| On Thu, Nov 10, 2005 at 03:59:17PM +0100, Pablo Braulio wrote:
|| > El Jueves, 10 de Noviembre de 2005 14:28, Iñaki escribió:
|| > > A mí esto de los módulos me trae frito, se supone que se cargan bajo
|| > > demanda, automáticamente, pero es mentira... a veces sí y a veces no,
|| > > sin seguir un criterio comprensible. O igual es que yo no lo entiendo
|| > > muy bien.
|| >
|| > Yo tampoco lo tengo nada claro. Los cargo haciendo modprobe o modconf, y
|| > generalmente se cargan, pero algunas veces al inicio no se cargan, y
|| > como consecuencia de ello algo falla (alsa, usb, etc)
|| >
|| > A ver si alguien nos lo puede explicar. Si es que tiene explicación.
||
|| Lo intento.
||
|| Los módulos se cargan bajo demanda, pero para que eso ocurra la
|| demanda debe llegar al kernel. En 2.2 uno tenía en /dev una entrada
|| para cada dispositivo que pudiera existir. Esa entrada tiene los
|| numeros de dispositivo mayor y menor. Cuando un programa abría el
|| nodo, el kernel sabía que ningún driver estaba registrado para manejar
|| esos números de dispositivo e iba a buscar el módulo adecuado, que
|| cargaba con modprobe. Esto funcionaba, pero cada que alguien inventaba
|| un dispositivo nuevo había que crear a mano los nodos en /dev. Y había
|| que asignar un par de números para el dispositivo, en forma estática y
|| centralizada.
||
|| En 2.4 se introdujo devfs. Con ese sistema, /dev arrancaba vacio y
|| cada módulo al cargarse notificaba su nombre favorito a devfs, que le
|| asignaba el número al que iba a responder y creaba el nodo en
|| /dev. Cuando un programa intentaba abrir un nodo no existente el aviso
|| llegaba a un demonio (devfsd) que consultaba su configuración y
|| cargaba el módulo correspondiente lo que a su vez hacía que devfs creara
|| el nodo. Para cuando el control regresaba al programa original el nodo
|| ya existía, el módulo estaba cargado y todos eran felices. Excepto,
|| por supuesto, los hackers del kernel, que tuvieron que aventarse la
|| bronca de mantener funcionando un pedazo de código altamente mágico,
|| con la desventaja adicional de que el autor original se desapareció de
|| las listas de desarrollo. Otro problema es que devfs no hacía nada
|| respecto al tema de reaccionar cuando de quitan o añaden dispositivos
|| al vuelo.
||
|| Entonces, en 2.6, se introdujeron udev y hotplug. udev hace más o
|| menos lo mismo que devfs, reacciona cuando se carga un módulo y crea
|| la entrada correspondiente en /dev. Hotplug reacciona ante los cambios
|| en el hardware y carga o elimina módulos cuando es necesario. Pero ya
|| no hay nada que intente cargar módulos cuando un programa trata de
|| usar un nodo de dispositivo no existente. El nodo tiene que existir
|| desde antes.
||
|| Respecto al hw que existe desde que arranca la máquina, se supone que
|| el kernel lo descubre durante la inicialización y guarda una lista,
|| que se le pasa a hotplug cuando el sistema ya está inicializado para
|| que cargue los módulos necesarios. Pero en mi experiencia esto no
|| siempre funciona bien. A mi me ha funcionado usar _discover_. Éste
|| corre durante la secuencia de arranque, verifica el hw existente y
|| carga los módulos necesarios. Esto me ha solucionado problemas con
|| alsa y usb sin tner que andar configurando el /etc/modules.
||
|| --
|| Rodrigo Gallardo
Muchas gracias por la fantástica explicación, creo que no puede venir muy bien
a más de uno.
Sólo añadir que en las últimas versiones de "udev" lleva integrado lo que
antes era el paquete separado "hotplug", así que ahora sólo existe "udev".
Gracias de nuevo y un saludo.
--
que a mí ni me va ni me viene... pero por comentar...
Reply to: