[Linuxtrent] Re: caricamento di un modulo al boot
- From: Marco Cova <giardini@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Tue, 16 Jul 2002 11:22:56 -0700
On Tue, Jul 16, 2002 at 03:54:01PM +0200, ianezz@xxxxxxxxxx wrote:
>
> Il generatore automatico di messaggi di Cristiano Tomasi ha generato:
>
>
> > La mia domanda e`: dove diavolo trova linux l'elenco dei moduli da
> > installare?
>
> Due cose da sapere riguardo ai moduli:
>
> 1) il caricamento di alcuni moduli viene effettuato al volo quando ce
> n'e` bisogno (se il kernel e` stato compilato per comportarsi
> cosi`, ed e` la stragrande maggioranza dei casi).
>
> Tipicamente cio` succede quando si tenta di accededere a un block
> device o ad un char device in /dev.
>
> Ad esempio, quando si tenta di accedere ad un dispositivo SCSI, il
> kernel di fatto manda in esecuzione un bel
>
> modprobe block-major-8
>
> e normalmente, in /etc/modules.conf c'e` un bel
>
> alias block-major-8 <nome_modulo_scsi_specifico>
>
>
> per cui l'effetto finale e` quello per cui vien fatto un modprobe
> del modulo specifico, che risulta nel caricamento del modulo e di
> tutti gli altri moduli da cui esso dipende. Bello, eh? :-)
>
Per essere pignoli (;-)) e perche' ci stavo guardando qualche di' fa:
il kernel esegue modprobe -s -k (attraverso una call a request_module())
-s per fare il logging attraverso syslogd e
-k per impostare l'autocleaning sul modulo caricato (o moduli)
dopo aver adeguatamente settato l'environment. E' da notare che
modprobe _deve_ trovarsi nella directory /sbin (perche' il path e'
hardcoded nel codice) (kernel/kmod.c)
questo meccanismo e' piuttosto singolare: il kernel invoca un
programma in userspace. Da quanto capisco, e' stato scelto di fare
cosi' perche' questa strategia semplificava di molto la gestione del
loading on demand dei moduli (i.e. non si deve replicare buona parte
di quello che fa modprobe in kernel space, modprobe permette
una discreta flessibilita' e configurabilita', vedi le varie
pre-install/post-install/pre-remove/post-remove).
sembra che la cosa sia piaciuta, perche' in realta' il kernel offre un
meccanismo del tutto generale per richiedere l'esecuzione di
programmi in userspace: call_usermodehelper, che apparentemente
funziona come la nota execve(2).
note per kernel hackers: call_usermodehelper() e request_module() sono
sincrone, i.e. dormono finche' il programma invocato non e' terminato
(con ovvie conseguenze su gestione di lock/semafori e necessita' di
scrivere codice rientrante) e non c'e' verso di sapere se l'azione
fatta dal programma invocata si e' conclusa con successo o meno
(per cui il codice e' simile a:
available = check_for_feature();
if (!available) request_module("feature");
if (!check_for_feature()) goto error
else goto success
)
that's all (scusate la lungaggine)
Marco
References:
kernel/kmod.[hc]
Documentation/modules.txt
net/socket.c per un esempio di come usare request_module()
http://www.xml.com/ldd/chapter/book/ch11.html
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con SOGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts:
