Miré en mi sistema y aptitude reporta 2 discover distintos, "discover" que trabaja con libdiscover2 y "discover1" que trabaja con libdiscover1. Ambos tienen conflictos el uno con el otro. Tengo instalado discover1, aunque no recuerdo haberlo instalado yo. Y por la explicacion en "aptitude show discover1" parece ser el correcto. Nos podés explicar qué diferencia hay entre uno y otro y en qué caso usar cada uno?
Gracias Ricardo El Jueves 10 Noviembre 2005 15: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
