Chiarimenti su Kernel Linux e caricamento moduli all'avvio

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Rispondi
ChriD
Linux 2.x
Linux 2.x
Messaggi: 362
Iscritto il: dom 30 ott 2005, 16:43

Chiarimenti su Kernel Linux e caricamento moduli all'avvio

Messaggio da ChriD »

Salve, apro questa discussione per chiedervi un chiarimento tecnico relativo al kernel Linux e al modo con cui vengono carica sia in maniera statica che dinamica i drivers dei vari dispositivi....
Non metterò' mai mano al codice di un kernel Linux in quanto non ne sarei ne capace ne tanto meno ne avrei la necessita'.... Quello che pero' vorrei capire e' la dinamica di funzionamento.... Quello che so e' che il codice dei driver open puo' essere presente sia in forma statica che in forma dinamica all'interno del kernel... Ora quello che vorrei sapere e' come e' possibile a livello software l'identificazione della presenza di un determinato tipo di hardware e quindi l'associazione di una determinata porzione di codice (driver) per il suo funzionamento. Esiste un id unico che identifica una determinata scheda di rete, una determinata scheda video a cui si sa che dovra' essere per forza associata quella porzione di codice per il suo funzionamento?
Stesso discorso per i moduli, quei file object del kernel presenti in /lib/modules/kernel-version/...., chi dice al kernel che deve caricare in memoria un certo modulo piuttosto che un altro?
Dando ad esempio un lspci -vvvs su bus 00 e device 03 (corrispondente alla scheda di rete) ottengo quanto segue...

Codice: Seleziona tutto

bash-4.3$ sudo lspci -vvvs 00:03.00
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
        Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (63750ns min)
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at e8400000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at c190 [size=8]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
        Capabilities: [e4] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=1
                Status: Dev=ff:1f.0 64bit- 133MHz- SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
        Kernel driver in use: e1000
        Kernel modules: e1000
Sulla base di cosa il kernel carica il modulo e1000?
Ho trovato una guida a questo indirizzo che dovrebbe trattare l'argomento in questione anche se non troppo recente... http://www.tldp.org/HOWTO/html_single/Module-HOWTO/

In particolare quoto il seguente passo...
5.4.1.1. Kernel Module Loader

There is some documentation of the kernel module loader in the file Documentation/kmod.txt in the Linux 2.4 source tree. This section is more complete and accurate than that file. You can also look at its source code in kernel/kmod.c.

The kernel module loader is an optional part of the Linux kernel. You get it if you select the CONFIG_KMOD feature when you configure the kernel at build time.

When a kernel that has the kernel module loader needs an LKM, it creates a user process (owned by the superuser, though) that executes modprobe to load the LKM, then exits. By default, it finds modprobe as /sbin/modprobe, but you can set up any program you like as modprobe by writing its file name to /proc/sys/kernel/modprobe. For example:
# echo "sbin/mymodprobe" >/proc/sys/kernel/modprobe

The kernel module loader passes the following arguments to the modprobe: Argument Zero is the full file name of modprobe. The regular arguments are -s, -k, and the name of the LKM that the kernel wants. -s is the user-hostile form of --syslog; -k is the cryptic way to say --autoclean. I.e. messages from modprobe will go to syslog and the loaded LKM will have the "autoclean" flag set.

The most important part of the modprobe invocation is, of course, the module name. Note that the "module name" argument to modprobe is not necessarily a real module name. It is often a symbolic name representing the role that module plays and you use an alias statement in modules.conf to tell what LKM gets loaded. For example, if your Ethernet adapter requires the 3c59x LKM, you would have probably need the line
alias eth0 3c59x
in /etc/modules.conf. Here is what the kernel module loader uses for a module name in some of the more popular cases (there are about 20 cases in which the kernel calls on the kernel module loader to load a module):


When you try access a device and no device driver has registered to serve that device's major number, the kernel requests the module by the name block-major-N or char-major-N where N is the major number in decimal without leading zeroes.

When you try to access a network interface (maybe by running ifconfig against it) and no network device driver has registered to serve an interface by that name, the kernel requests the module named the same as the interface name (e.g. eth0). This applies to drivers for non-physical interfaces such as ppp0 as well.

When you try to access a socket in a protocol family which no protocol driver has registered to drive, the kernel requests the module named net-pf-N, where N is the protocol family number (in decimal without leading zeroes).

When you try to NFS export a directory or otherwise access the NFS server via the NFS system call, the kernel requests the module named nfsd.

The ATA device driver (named ide) loads the relevant drivers for classes of ATA devices by the names: ide-disk, ide-cd, ide-floppy, ide-tape, and ide-scsi.

The kernel module loader runs modprobe with the following environment variables (only): HOME=/; TERM=linux; PATH=/sbin:/usr/sbin:/bin:/usr/bin.

The kernel module loader was new in Linux 2.2 and was designed to take the place of kerneld. It does not, however, have all the features of kerneld.

In Linux 2.2, the kernel module loader creates the above mentioned process directly. In Linux 2.4, the kernel module loader submits the module loading work to Keventd and it runs as a child process of Keventd.

The kernel module loader is a pretty strange beast. It violates layering as Unix programmers generally understand it and consequently is inflexible, hard to understand, and not robust. Many system designers would bristle just at the fact that it has the PATH hardcoded. You may prefer to use kerneld instead, or not bother with automatic loading of LKMs at all.
Supponendo quindi che esista questo modules.conf che nella Slackware 14.2 non ho trovato, sostituito credo da modules.alias in /lib/modules/ver-kernel, allora la domanda e' ma chi lo costruisce e mantiene aggiornato questo file di associazioni tra device name (identificativo variabile credo) e nome modulo da caricare?
Il file viene generato in fase di compilazione del kernel, make modules? Successivamente i vari drivers che s'installano lo aggiornano?
Mi piacerebbe approfondire con voi il discorso....

Rispondi