Axel Heinrici wrote:
Erstmal vorweg, ich habe mich jetzt doch für alsa entschieden. War einfacher als ich dachte und YaST arbeitet auch nciht mehr gegen einen.
Hab' ich doch gesagt :-)
Ich würde diese Modul-Geschichte aber gerne noch etwas besser verstehen, um nich jedesmal bei einem ählichen Problem wieder nachfragen zu müssen. Wenn ich mir man 5 modules.conf durchlese, dann steht da ganz oben "...DESCRIPTION The behavior of modprobe(8) (and depmod(8) ) can be modified ... ". Für mich stellt sich da immernoch die Frage: "Welchen Mechanismus soll dieser Alias in Gang setzten? Wann soll dieses Modul denn nun von wem geladen werden?"
Sobald der Kernel ein Ereignis entdeckt, fuer das er selbst keine Unterstuetzung hat (z.B. die Unterstuetzung fuer ein Filesystem oder die Unterstuetzung fuer den Zugriff auf ein Device, den seriellen Port z.B.), dann wird der Kernel Module Loader (kmod) aktiv. Ueber einen modprobe-Befehl (oder genauer: ueber das Programm, was die Ausgabe von "cat /proc/sys/kernel/modprobe" bei Kernel 2.4 ergibt; in der Regel ist das /sbin/modprobe) wird versucht, ein Modul zu laden, was die angeforderte Unterstuetzung bereit stellt. Das Modul wird registriert und der Kernel kann nun die Aufgabe ausfuehren, die er urspruenglich erledigen sollte. Wird kein Modul "gefunden", das die angeforderte Unterstuetzung bereit stellt, so kann der Kernel logischerweise seine Aufgabe nicht erfuellen und es wird eine Fehlermeldung ausgegeben... Stellt sich die Frage, woher nun bekannt ist, welches Modul genau geladen werden soll, wenn o.a. Fall auftritt. Da gibt es verschiedene Moeglichkeiten und da kommt dann auch die Datei /etc/modules.conf (bei Kernel 2.4) ins Spiel, denn sie ist die Konfigurationsdatei fuer modprobe. Beim Zugriff auf ein Device mit der Major Number N (siehe dazu auch die Datei /usr/src/linux/Documentation/devices.txt) wird versucht, ein Modul mit dem Namen block-major-N bzw. char-major-N zu laden, je nachdem, ob es sich um den Zugriff auf ein Block oder Character Device handelt. Entsprechend gibt es Eintraege in /etc/modules.conf. Der NVIDIA-Treiber benutzt z.B. ein Device mit Major Number 195, wie Du leicht per "ls -l /dev/nvidia*" feststellen kannst (so Du eine NVIDIA-Karte hast): crw-rw-rw- 1 root root 195, 0 2004-01-14 18:09 /dev/nvidia0 crw-rw---- 1 root video 195, 0 2003-03-14 14:08 /dev/nvidia00 crw-rw---- 1 root video 195, 1 2003-03-14 14:08 /dev/nvidia01 crw-rw---- 1 root video 195, 2 2003-03-14 14:08 /dev/nvidia02 crw-rw---- 1 root video 195, 3 2003-03-14 14:08 /dev/nvidia03 crw-rw-rw- 1 root root 195, 1 2004-01-14 18:09 /dev/nvidia1 [...] Es handelt sich also alles um Character Devices (siehe das "c" zu Beginn der Zeile) mit Major Number 195. Entsprechend findest Du dann einen Eintrag alias char-major-195 nvidia in der /etc/modules.conf. Uebersetzt heisst das schlicht, "bei Zugriff auf ein Character Device mit der Major Number 195, lade das Modul nvidia.o". Dafuer steht der Alias. Beim Zugriff auf ein Netzwerkinterface, das bisher von keinem Treiber registriert wurde, wird schlicht ein Modul angefragt, das den Namen des Interfaces traegt. Beim Interface eth0 wird also versucht, ein Modul mit Namen eth0 zu laden (das gibt es aber physikalisch nicht). In der Datei /etc/modules.conf findest Du deswegen z.B. einen Eintrag wie "alias eth0 ne2k-pci" (so siehst das bei mir aus, bei Dir evtl. eben anders, wenn Du einen anderen Treiber fuer Deine Netzwerkkarte brauchst) - das bedeutet wie oben bereits beschrieben, dass das Anfordern eines Modules fuer eth0 in das Laden des Modules "ne2k-pc.o" umgesetzt wird. Sollte eigentlich einleuchten, oder? Beim Zugriff auf ein Socket in einer Protokollfamilie, fuer das bisher kein Treiber registriert wurde, wird das Modul net-pf-N angefordert, wobei N diesmal die Nummer der Protokollfamilie ist. Beispiel hierfuer waere "alias net-pf-5 appletalk". Die Nummer der Protokollfamilie findest Du z.B. in /usr/src/linux/include/linux/socket.h. Der ATA Device-Treiber (ide) laedt die Treiber fuer gewisse Klassen von Geraeten durch Namen: ide-disk, ide-cd, ide-floppy, ide-tape und, wenn man es etwas verallgemeinert, auch ide-scsi (siehe dazu Archiv der Liste; mit ide-scsi ist es etwas besonderes - das schreibe ich hier mal besser dazu, sonst widerspricht mir David wieder :-) Ein "alias <name> off" in /etc/modules.conf besagt, dass jegliche Anfrage, ein derartiges Modul zu laden, ignoriert wird. Kann kein geeignetes Modul gefunden werden, so bekommt man z.B. "modprobe: Can't locate module char-major-195" zu sehen (bzw. man findet es dann in /var/log/messages) - das bedeutet dann uebersetzt, siehe oben, dass das Modul nvidia.o nicht gefunden werden kann. Oft der Fall, wenn ein neuer Kernel (oder ein Update) installiert und dabei vergessen wurde, das Kernel-Modul des NVIDIA-Treibers neu zu erstellen fuer den neuen Kernel. Wird ein Modul korrekt geladen, obwohl kein entsprechender Eintrag in der Konfigurationsdatei /etc/modules.conf vorkommt, so darf man sich nicht wundern. Modprobe hat bereits einige Aliase fest einprogrammiert, die man in der Datei util/alias.h bei den modutils-Quellen nachlesen kann. Die Datei /etc/modules.conf ist also die zentrale Konfigurationsdatei fuer modprobe und damit zum automatischen Laden von Kernel-Modulen. Wie oben erklaert, wird dort geregelt, welches Modul wann zu laden ist. Aber es koennen auch gewisse Optionen zum Laden eines Modules angegeben werden (das sind dann die Zeilen, die mit "options" beginnen, z.B. "options eepro io=0x260 irq=10 mem=0x6000") oder es koennen beim Laden eines Modules automatisch weitere Module nachgeladen (oder auch vorher gelanden) werden. Ein Beispiel waere hier: pre-install radeon /sbin/modprobe "-k" "agpgart". Umgekehrt nennt man es dann post-install, z.B.: post-install bttv /sbin/modprobe "-k" tuner. Auch fuer das Entfernen von Modulen gibt es Regeln, u.v.m. All das steht in "man modules.conf" erklaert. Ueber "depmod" werden automatisch Abhaengigkeiten zwischen Modulen ermittelt, Du findest das dann in der Datei modules.dep in /lib/modules/`uname -r`. Wenn Du Dir die Datei anschaust, dann sieht das so aehnlich aus wie bei Abhaengigkeiten in einem Makefile (das wird Dir natuerlich nur bekannt vorkommen, wenn Du Dich auch mit Makefiles auskennst :-) Wenn depmod nicht in der Lage ist, ein Symbol zu finden, das fuer ein gewisses Modul gebraucht wird (dann wuerde das zu ladende Modul von einem anderen Modul abhaengen, was das Symbol bereit stellt), so bekommst Du die beruechtigte Meldung ueber "Unresolved symbols in <module-name>"... Ein derartiges Modul, was diese Meldung verursacht, kann nicht geladen werden, weil fuer dessen Funktionalitaet etwas fehlt. Ferner legt depmod noch einige Map-Dateien an, die sind dann fuer hotplug. Ich hoffe, dass diese Erklaerung Dich einigermassen zufrieden stellt. Gruesse, Thomson