[PLUTO-help] Gestione dei moduli nei kernel recenti

[t1m3]

Ho qualche domanda piuttosto tecnica, che probabilmente sarebbe più
giusto inviare a pluto-tech, lista che però mi pare (dagli archivi)
ferma da alcuni mesi. Per sicurezza, quindi, invio qui e, semmai, ditemi
se è meglio che, invece, faccia la domanda a pluto-tech.
Grazie.

******

Se ho capito bene, udev non si occupa del caricamento dei moduli, ma si
occupa di creare e cancellare in modo dinamico i nodi in /sys utili a
gestire le interfacce di comunicazione coi device e di applicare alcune
regole al momento della creazione delle interfacce.

Ho un device USB 2.0 che viene pilotato da ehci_hcd. Se io rimuovo dal
kernel (con modprobe -r o con rmmod) il modulo ehci_hcd, il controllo
del device USB 2.0 viene spostato a uhci_hcd (o ohci_hcd).
Se, in un secondo tempo, inserisco un altro device USB 2.0 (o tolgo e
poi reinserisco il medesimo), il kernel provvede da solo a ricaricare
ehci_hcd mandando un uevent a udevd.
A questo punto, ehci_hcd si si riappropria anche del controllo del
device precedentemente spostato da ehci_hcd a uhci_hcd (EHCI prevale su
UHCI se caricato dopo quest'ultimo: vedi http://a2.pluto.it/a2105.htm ).

E' giusto questo schema?

Domande collegate:

1) quando scarico un modulo, ma poi avviene un evento hotplug (con lo
stesso device --per esempio: l'ho tolto e poi l'ho reinserito-- oppure
con un altro device che utilizza lo stesso modulo), il kernel provvede
da solo a ricaricare il modulo?

2) se ho messo un modulo in blacklist, il kernel eviterà sempre (e non
solo al momento del boot) di caricare in automatico quel modulo?

3) se ho messo un modulo in blacklist, poi posso caricarlo comunque a
mano con modprobe (o insmod)?

Se 1) è vera, allora vuol dire che modprobe -r (o rmmod) è un'operazione
che serve solo fino al prossimo evento di hotplug che comporta un
richiamo di quel modulo. Giusto?

4) Qual è il componente che si occupa dell'assegnazione di un modulo a
un certo device? Voglio dire: il kernel, per caricare in automatico, un
determinato modulo dovrà sapere che è proprio quel modulo lì che serve
per pilotare il device. Quindi, sarei tentato di rispondere che è il
kernel che si occupa del matching fra device e moduli (e che sposta
anche il controllo a uhci_hcd se ehci_hcd viene rimosso). In base a
quali informazioni lo fa? Sulla base delle informazioni contenute nei
moduli stessi?

5) Dunque, se 4) è vera, udev si occupa solo di inserire e rimuovere i
nodi nel filesystem virtuale /sys e di applicare certe regole in
presenza dei device. Giusto?

Vediamo un esempio concreto. Ho un cellulare Nokia al quale viene
assegnato il modulo (driver) cdc_acm. Dove sta scritta l'informazione
per cui con quel determinato cellulare il driver cdc_acm va bene? Nel
sorgente di cdc_acm?

http://lxr.linux.no/linux+v2.6.18.8/Documentation/usb/acm.txt#L31
"The drivers/usb/class/cdc-acm.c drivers works with USB modems and USB
ISDN terminal
adapters that conform to the Universal Serial Bus Communication Device
Class
Abstract Control Model (USB CDC ACM) specification."

http://lxr.linux.no/linux+v2.6.18.8/drivers/usb/class/cdc-acm.c
(Sorgente di cdc-acm)
-- 
  t1m3
  ttt1m333 a ml1.net

-- 
http://www.fastmail.fm - Access all of your messages and folders
                          wherever you are