Genau meine Vermutung, was ich meinte mit "totaler Quatsch"
Was wollen wir sehen: Welche exakte Firmware-Datei wird von unseren geladenen Modulen geladen?
"dyndbg=func fw_log_firmware_info +p"
erfüllt genau das.
Dein Aufruf mit:
"dyndbg=file firmware/*.c +p"
debugged aktuell jedes .c File - bezogen auf den Kernel-Sourcecode! . //Edit2: siehe unten ²
Deshalb ist dein journal auch so gemüllt.
Weil: Alles was ein .c FILE im Kernelsource(also im laufenden Kernel) auch ausgeben würde, das wird durch +p auch geloggt (ggf. eingeschränkt durch den loglevel=x beim Boot).
Für die Aufgabe ist das dann - sorry, nicht bös gemeint - dann totaler Overkill!
Der match bei dyndbg kann sein:
match-spec ::= 'func' string |
'file' string |
'module' string |
'format' string |
'class' string |
'line' line-range
func nutzten wir oben, du nutzt file
file bedeutet:
file
The given string is compared against either the src-root relative pathname, or the basename of the source file of each callsite. Examples:
file svcsock.c
file kernel/freezer.c # ie column 1 of control file
file drivers/usb/* # all callsites under it
file inode.c:start_* # parse :tail as a func (above)
file inode.c:1-100 # parse :tail as a line-range (above)
Verstehst du das, daß match nach file *.c eben Humbug ist für unseren Fall?
Ansonsten kann ich gerne noch weitere "Beweise" anführen.
//Edit:
In deinem aktuellen Aufruf:
dyndbg=file drivers/base/firmware_loader/main.c +fmp"
beschränkst du das auf die Kernelsource-Datei drivers/base/firmware_loader/main.c
Aber genau darin ist ja auch die function fw_log_firmware_info. Warum also nicht mittels 'func'-match eben genau nur diese Funktion nutzen?
/edit2:
²
file firmware/*.c
würde sogar nur jedes C-File in einem relativen Verzeichnis firmware/*.c debuggen.
Das ist sehr eingeschränkt und erfasst somit nicht alle Module.
Deshalb bekamst du bei deinem Test in deinem Test-Skript auch nur:
tuxnix successfully loaded
r592: driver successfully loaded
dieses Modul (von diesem Sourcefile) angezeigt, Und das ist das Modul für einen (modinfo):
Ricoh R5C592 Memstick/Memstick PRO card reader driver
Weil: Im Kernelsource gibt es nur ein File firmware/*.c was im Quellcode den Sring "successfully loaded" ausgibt. Ohne die relative Beschränkung auf "firmware/" gibt es noch mehr.