Kmod: El carregador de mòduls del Kernel (The Kernel Module Loader)
Kirk Petersen
Traduït per Antoni Bella Perez

 Kmod és una simple substitució per a kernenld. Consisteix en una substitució
de la funció request_module() i un fil (thread) del kernel anomenat
kmod. Quan el kernel necessita un mòdul, kmod es desperta i
executa modprobe mitjançant execve(), passant-li el nom demanat.

 Si té el sistema de fitxers /proc muntat, pot especificar la
path per a modprobe (a on el kernel el buscarà) fent:

	echo "/sbin/modprobe" > /proc/sys/kernel/modprobe

 Per a descarregar periòdicament els mòduls no usats, posi alguna cosa
com la següent en una entrada de crontab de l'usuari root:

	0-59/5 * * * * /sbin/rmmod -a

 Kmod només càrrega mòduls. Kerneld podia fer més (encara que res en el
kernel estàndard utilitzava les seves altres funcionalitats). Si vostè
requereix característiques com request_route, li suggerim que agafi una
aproximació semblant. Una simple funció request_route podria ser
cridada, i un fil kroute en el kernel ser executat per a fer la
feina. Però probablement hauríem de mantenir això al mínim.

 Kerneld tenia també un mecanisme per a emmagatzemar les característiques
o paràmetres dels drivers de dispositiu. Això pot fer-se fàcilment
amb modprobe. Quan un mòdul és descarregat, modprobe podria mirar
en algun lloc de configuració per a cada driver (/proc/sys/drivers/blah)
per a emmagatzemar en un fitxer els paràmetres de configuració del
driver de dispositiu. Quan un mòdul és carregat, simplement hauria
bolcar dit fitxer al lloc adequat del sistema de fitxers /proc.
O tal vegada un script podria ser un paràmetre en /etc/modules.conf.
Hi ha moltes maneres que podria funcionar (jo prefereixo usar /proc).

 Si kerneld funcionava, per què reemplaçar-lo?

- kerneld usava sysv IPC, que ara pot ser creat com a mòdul.
  A banda, sysv IPC és lleig i hauria de ser evitat (almenys per les
  coses a nivell de kernel).

- Ambdós Kmod i Kerneld acaben fent la mateixa cosa (anomenar a
  modprobe), així que... perquè no evitar l'home intermedi?

- eliminar les coses relacionades amb kerneld de ipc/msg.c el
  va fer un 40% més petit de mida.

- kmod informa dels errors a través dels mecanismes normals
  del kernel, la qual cosa evita el problema entre kerneld i els socks
  modulars de dominis Unix.


Keith Owens <kaos@ocs.com.au> Decembre de 1999

La combinació de kmod i modprobe pot enllaçar-se loop, especialment si modprobe
usa una crida al sistema que requereixi un mòdul. Si modules.dep no existeix i
s'ha executat modprobe amb l'opció -s (això és kmod), modprobe intentarà un
missatge syslog(). syslog() nessecita connexions Unix, si les connexions Unix
son modulars llavors kmod executa "modprobe -s net-pf-1". Això controla una
segona còpia de modprobe la qual es queixa de que modules.dep no existeix,
intenta usar syslog() i executar una altre còpia de modprobe. Aquest no és
l'únic enllaç posible entre kmod/modprobe, sols el més comú.

Per a detectar els enllaços causats per "modprobe necessita d'un servei que es
troba en un mòdul", kmod limita el nombre de kmod simultanis amb modprobes. Miri
MAX_KMOD_CONCURRENT en kernel/kmod.c. Quan aquest límits s'hagi excedit, el
missatge del nucli
  "kmod: runaway modprobe loop assumed and stopped"
i la traducció
  "kmod: l'enllaç descontrolat de modprobe asumit i parat".

Noteu els usuaris que construeixen un sistema molt moduralitzat. Aquesta és una
bona idea, crear modules.dep despres d'instal·lar els mòduls i despres de
carregar el nucli per primera vegada. "depmod -ae m.n.p" a on m.n.p seria la
nova versió del nucli.