Eigentlich gehören die Module gerichtet. Wenn man es neu definiert, dann bitte so:
Code#define __devinit __init ....
Es gehört dann in compat.h rein.
Gruß
e9hack
Und in welche?
vdr01_64 src # find media_build_experimental -name compat.h
media_build_experimental/v4l/compat.h
media_build_experimental/experimental/ngene-octopus-test/v4l/compat.h
media_build_experimental/experimental/v4l-dvb-saa716x/v4l/compat.h
vdr01_64 src #Eigentlich gehören die Module gerichtet.
Fuer saa716x bin ich gerade dabei.
Wenn man es neu definiert, dann bitte so:
Quellcode
#define __devinit __init
....
Unfug!
S:oren
Unfug!
Hast natürlich recht. Wenn, dann so:
vdr:/usr/src/media_build_experimental/v4l # hg diff compat.h
diff -r 9b79c0d0acf1 v4l/compat.h
--- a/v4l/compat.h Sat Feb 02 09:01:28 2013 +0100
+++ b/v4l/compat.h Sat Feb 23 16:51:53 2013 +0100
@@ -1095,4 +1092,32 @@
#define VM_DONTDUMP VM_NODUMP
#endif
+#ifndef __devinit
+#define __devinit __init
+#endif
+
+#ifndef __devinitdata
+#define __devinitdata __initdata
+#endif
+
+#ifndef __devinitconst
+#define __devinitconst __initconst
+#endif
+
+#ifndef __devexit
+#define __devexit __exit
+#endif
+
+#ifndef __devexitdata
+#define __devexitdata __exitdata
+#endif
+
+#ifndef __devexitconst
+#define __devexitconst __exitconst
+#endif
+
+#ifndef __devexit_p
+#define __devexit_p __exit_p
+#endif
+
#endif /* _COMPAT_H */Und da Du ja gerade am Ändern bist, kannst Du auch gleich alle Warnings mit abstellen:
/usr/src/media_build_experimental/v4l/saa716x_rom.c: In function 'saa716x_eeprom_header':
/usr/src/media_build_experimental/v4l/saa716x_rom.c:115: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
/usr/src/media_build_experimental/v4l/saa716x_rom.c:115: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
...
Gruß
e9hack
Hast natürlich recht. Wenn, dann so:
Entschuldigung, aber das ist (fast) immer noch der gleiche Bloedsinn. Die __devinit (and friends) muessen ersatzlos geloescht werden, wie ich schon geschrieben hatte und jasminj den Code gebaut hat.
Und da Du ja gerade am Ändern bist, kannst Du auch gleich alle Warnings mit abstellen:
Sollte da ein Fragezeichen dahinter?
Gruss,
S:oren
e9hack:
Alles was man dazu wissen muss steht in dem Post. Wenn du das genau gelesen und verstanden hättest, hättest du erkannt, dass diese Defines ELIMINIERT wurden und somit für Kernel 3.8 nicht mehr notwendig sind. Sprich ERSATZLOS gestrichen werden MÜSSEN.
Nachdem es sich bei media-experimental aber um ein Patchset für einen älteren Kernel handelt, können wir das nicht so einfach angreifen und die Attribute löschen.
ZitatEigentlich gehören die Module gerichtet. Wenn man es neu definiert ...
Um das Perfekt zu machen, müsste man die Defines im passenden globalen Header File ".../compat.h" abhängig von der Kernel Version einmal so definieren wie bisher ( pre 3.8 ) und einmal als leer ( >= 3.8 ), falls sie nicht bereits definiert sind. Anders wird man es nicht kompatibel bekommen. ddbridge-core.c includiert dieses File aber auch nicht. Möglicherweise über ein anderes. Ich kann das jetzt nicht testen, weil ich keinen 3.8 Kernel installiert habe und mich eigentlich um mein CAM kümmern will.
Aber nachdem du ja so g'scheit bist, kannst du uns ja diesbezüglich in Kürze mit einem Patch beglücken.
3PO: Ich würde die paar Zeilen, die ich gepostet habe, in /usr/src/linux-headers-3.8.xxxx/include/linux/init.h kopieren (vorher eine Sicherheitskopie machen) und dann sollte dein Problem vorerst mal behoben sein. Wenn uns dann e9hack den Patch für media-experimental geschickt hat, dann kannst ja die init.h wieder zurück kopieren.
LG
Jasmin
[...] 3PO: Ich würde die paar Zeilen, die ich gepostet habe, in /usr/src/linux-headers-3.8.xxxx/include/linux/init.h kopieren (vorher eine Sicherheitskopie machen) und dann sollte dein Problem vorerst mal behoben sein. Wenn uns dann e9hack den Patch für media-experimental geschickt hat, dann kannst ja die init.h wieder zurück kopieren.
LG
Jasmin
Jetzt mal abgesehen davon, dass es "/usr/src/linux-headers......" bei mir nicht gibt, habe ich eigentlich nicht vor, soweit in das System einzugreifen. Ich kann ja auch bei kernel-3.7.8 bleiben. 
Aber trotzdem vielen Dank für die Tipps. 
Nachdem es sich bei media-experimental aber um ein Patchset für einen älteren Kernel handelt, können wir das nicht so einfach angreifen und die Attribute löschen.
Ich halte des komplette Löschen der __devinit (and friends) für absolut ungefährlich (und heutzutage ohne jede Nebenwirkung).
Es scheint mir, dass hier die Bedeutung dieser Attribute nicht so recht klar ist. Deshalb mal der Versuch einer Erklärung:
Es war einmal eine Zeit, als Linux auf Rechnern lief, bei denen der Hauptspeicher in einzelnen Megabytes gezählt wurde. Da kamen findige Programmierer auf die Idee, Code, der nur einmal beim Start des Kernels zur Initialisierung der Hardware ausgeführt wird, in eine eigene init-Codesection auszulagern, die nach dem Hochfahren des Kernels aus dem Hauptspeicher gelöscht wird. Mit der Zeit wurden die Hauptspeicher größer und es wurden Geräte entwickelt, die man zur Laufzeit des Systems einfach so an- und abstecken konnte (z.B. USB). Dumm war nun, dass der Kernel den Code zur Initialisierung dieser Geräte bereits gelöscht hatte, diese Geräte waren also nicht verwendbar. Um nun diesen Init-Code wahlweise behalten zu können, führte man konfigurierbaren Hotplug-Support im Kernel ein. Code zur Initialisierung von solchen Geräten wurde statt __init mit __devinit (entsprechend für Daten) gekennzeichnet. Ist nun Hotplug nicht konfiguriert, wird _devinit wie __init behandelt, ist Hotplug konfiguriert, wird __devinit wie normaler Code ohne Attribut behandelt (entsprechend fuer Daten). Die Zeit vergeht und mittlerweile haben auch kleine embedded Computer Hauptspeicher von einem halben Gigabyte oder mehr und USB-Controller. Somit baut schon jahrelang niemand mehr Kernel ohne Hotplug-Support.
Bei linux-3.8 hat man nun etwas aufgeräumt, z.B. Support für den alten i386 entfernt, und auch das konfigurierbare Hotplugging nun per default immer eingeschaltet. __devinit hat nun keine Bedeutung mehr und wurde vollständig entfernt. Bei älteren Kerneln könnte man ein paar Byte Hauptspeicher mit __devinit sparen, aber nur dann, wenn Hotplugging deaktiviert ist. Verwendet irgendjemand hier einen Kernel ohne Hotplug-Support?
Entschuldigung an UFO für diese off-topic-Diskussion.
Gruß,
Sören
... Und wenn sie nicht gestorben sind, dann Entwickeln sie noch heute.
*SNCR*
Ich halte des komplette Löschen der __devinit (and friends) für absolut ungefährlich (und heutzutage ohne jede Nebenwirkung).
Ja schön, aber wer geht die 100 Files von media-experimental durch und löscht die Attribute?
Wenn UFO auf einen neuen Stand vom media-tree upgraded, dann sind ja viele der notwendigen Änderungen schon dabei. Was dann noch fehlt, weil in Patches, muss man zu dem Zeitpunkt machen. Sprich wenn UFO sich die Zeit nehmen kann.
Ausganspunkt war die Frage von 3PO nach Hilfe mit dem derzeit verfügbaren media-experimetal und Kernel 3.8. Und da braucht es eben noch die leeren Defines.
LG
Jasmin
[...] Ja schön, aber wer geht die 100 Files von media-experimental durch und löscht die Attribute? ...
Wie wäre es, wenn das Kollege sed übernehmen würde?
Kann mich noch erinnern, daß Treiber gepatcht werden mußten, um dieses bescheuerte Attributzeugs einzuführen. Ich bezweifle, daß die Speicherersparnis jemals in einem vernünftigen Verhältnis zum Aufwand stand. Jetzt wurde es halt wieder abgeschafft. Toll.
Scheint zu jeder Zeit Leute zu geben, die nichts Wichtiges zu tun haben. 
Beim nächsten Merge von media_build_experimental mit Upstream-media_build werde ich mir das anschauen. Kann allerdings noch etwas dauern. Bis dahin müssen sich die Leute mit 3.8+ eben mit ein paar leeren #defines behelfen.
CU
Oliver
Ich halte des komplette Löschen der __devinit (and friends) für absolut ungefährlich (und heutzutage ohne jede Nebenwirkung).
Es scheint mir, dass hier die Bedeutung dieser Attribute nicht so recht klar ist. Deshalb mal der Versuch einer Erklärung:
Es war einmal eine Zeit, als Linux auf Rechnern lief, bei denen der Hauptspeicher in einzelnen Megabytes gezählt wurde. Da kamen findige Programmierer auf die Idee, Code, der nur einmal beim Start des Kernels zur Initialisierung der Hardware ausgeführt wird, in eine eigene init-Codesection auszulagern, die nach dem Hochfahren des Kernels aus dem Hauptspeicher gelöscht wird. Mit der Zeit wurden die Hauptspeicher größer und es wurden Geräte entwickelt, die man zur Laufzeit des Systems einfach so an- und abstecken konnte (z.B. USB). Dumm war nun, dass der Kernel den Code zur Initialisierung dieser Geräte bereits gelöscht hatte, diese Geräte waren also nicht verwendbar. Um nun diesen Init-Code wahlweise behalten zu können, führte man konfigurierbaren Hotplug-Support im Kernel ein. Code zur Initialisierung von solchen Geräten wurde statt __init mit __devinit (entsprechend für Daten) gekennzeichnet. Ist nun Hotplug nicht konfiguriert, wird _devinit wie __init behandelt, ist Hotplug konfiguriert, wird __devinit wie normaler Code ohne Attribut behandelt (entsprechend fuer Daten). Die Zeit vergeht und mittlerweile haben auch kleine embedded Computer Hauptspeicher von einem halben Gigabyte oder mehr und USB-Controller. Somit baut schon jahrelang niemand mehr Kernel ohne Hotplug-Support.
Bei linux-3.8 hat man nun etwas aufgeräumt, z.B. Support für den alten i386 entfernt, und auch das konfigurierbare Hotplugging nun per default immer eingeschaltet. __devinit hat nun keine Bedeutung mehr und wurde vollständig entfernt. Bei älteren Kerneln könnte man ein paar Byte Hauptspeicher mit __devinit sparen, aber nur dann, wenn Hotplugging deaktiviert ist. Verwendet irgendjemand hier einen Kernel ohne Hotplug-Support?
Deine Erklärung scheint ja plausibel zu sein. Nur aktuell sind zwei PCI-Karten betroffen. Es wird ja wohl keiner bei laufendem PC die ddbridge- oder ffhd-Karte permanent ziehen bzw. wieder reinstecken wollen. Die ddbridge-Karte benutzt sowohl __xxxx als auch __devxxxx Attribute. Die __devxxxx Attribute kann man entfallen lassen, die anderen werden nicht angetastet. Irgendwie paßt das nicht zusammen.
Gruß
e9hack
Nur aktuell sind zwei PCI-Karten betroffen. Es wird ja wohl keiner bei laufendem PC die ddbridge- oder ffhd-Karte permanent ziehen bzw. wieder reinstecken wollen.
Fuer den Kernel sind alle PCI-Geraete hotplug-faehig. Der PCI(e)-Standard erlaubt das, es gibt Industriekarten, die tatsaechlich im Betrieb gewechselt werden duerfen. Auch die hier in Frage stehenden Karten koennten z.B. in einem externen Gehaeuse stecken, das ueber eine PCI-Bridge auf einer PCMCIA-Karte hot-pluggable z.B. an einem Laptop angeschlossen ist. (Ich kenne persönlich einen Entwickler solcher Boxen.)
Die ddbridge-Karte benutzt sowohl __xxxx als auch __devxxxx Attribute. Die __devxxxx Attribute kann man entfallen lassen, die anderen werden nicht angetastet. Irgendwie paßt das nicht zusammen.
Die __init-Attribute gibt es weiterhin auch in linux-3.8. Module-Init-Code wird z.B. tatsaechlich nur beim Laden des Moduls ausgefuehrt, der im Modul enthaltene probe-Code fuer Geraete aber ggf. jedesmal beim Anschliessen eines Geraetes. Ich habe keine Ahnung, ob in diesem speziellen Treiber die Attribute evt. inkorrekt benutzt werden.
Gruss,
S:oren
[...] Habe das __dev*-Gedöns aus ddbridge und ngene entfernt. ...
Dann bleiben ja nur noch 379 Einträge übrig.
vdr01_64 media_build_experimental # grep -r "__devexit" * |wc -l
379
vdr01_64 media_build_experimental #Die Frage ist nun, ob man die bedenkenlos einfach von sed entfernen lassen kann?
Es sind allerdings außer "__devexit" auch "__devexit_p" Einträge vorhanden. Können diese auch gelöscht werden?
Dann bleiben ja nur noch 379 Einträge übrig.
Du mußt nur auf ein aktuelleres Treiber-Packet umsteigen. Da ist alles gerichtet.
Gruß
e9hack
Da vom Kernel getrennte Treiber immer als Modul kompiliert werden müssen, war HOTPLUG schon immer Voraussetzung. Insofern verliert man nichts. Habe das __dev*-Gedöns aus ddbridge und ngene entfernt.
Wenn ddbridge HOTPLUG fähig sein soll, muß man das noch in ddb_device_create() und ddb_device_destroy() berücksichtigen. Aktuell wird der Treiber crashen, wenn man mehr als 32 ddbridge Karten verwendet oder wenn man die einzige Karte zum 32mal gezogen und wieder reingesteckt hat 
vdr:/usr/src/media_build_experimental/v4l # vdr:/usr/src/media_build_experimental # cat ddbridge-device-create-d130224.diff
--- linux/drivers/media/pci/ddbridge/ddbridge-core.c.save 2013-02-24 07:55:15.000000000 +0100
+++ linux/drivers/media/pci/ddbridge/ddbridge-core.c 2013-02-24 08:09:00.591162852 +0100
@@ -2157,7 +2157,6 @@
#define DDB_NAME "ddbridge"
-static u32 ddb_num;
static int ddb_major;
static DEFINE_MUTEX(ddb_mutex);
@@ -2512,12 +2511,19 @@
static int ddb_device_create(struct ddb *dev)
{
+ int i;
int error = -1;
mutex_lock(&ddb_mutex);
- dev->nr = ddb_num++;
- ddbs[dev->nr] = dev;
+ for (i = 0; i < sizeof(ddbs) / sizeof(ddbs[i]); i++)
+ if (!ddbs[i]) {
+ dev->nr = i;
+ ddbs[i] = dev;
+ break;
+ }
mutex_unlock(&ddb_mutex);
+ if (i >= sizeof(ddbs) / sizeof(ddbs[0]))
+ goto fail0;
dev->ddb_dev = device_create(&ddb_class, &dev->pdev->dev,
MKDEV(ddb_major, dev->nr),
dev, "ddbridge%d", dev->nr);
@@ -2539,10 +2545,9 @@
fail1:
mutex_lock(&ddb_mutex);
- ddb_num--;
ddbs[dev->nr] = NULL;
mutex_unlock(&ddb_mutex);
-
+fail0:
return error;
}
@@ -2552,6 +2557,9 @@
return;
ddb_device_files_delete(dev);
device_destroy(&ddb_class, MKDEV(ddb_major, dev->nr));
+ mutex_lock(&ddb_mutex);
+ ddbs[dev->nr] = NULL;
+ mutex_unlock(&ddb_mutex);
}Für Kernel 3.8 sollte man DEFINE_PCI_DEVICE_TABLE aus compat.h entfernen, da sich die Definition geändert hat. Eigentlich ist es in compat.h komplett überflüssig, da es die Definition schon relativ lange gibt.
diff -r 9b79c0d0acf1 v4l/compat.h
--- a/v4l/compat.h Sat Feb 02 09:01:28 2013 +0100
+++ b/v4l/compat.h Sun Feb 24 08:49:22 2013 +0100
@@ -174,10 +174,12 @@
#define KEY_IMAGES 0x1ba /* AL Image Browser */
#endif
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 8, 0)
#ifndef DEFINE_PCI_DEVICE_TABLE
#define DEFINE_PCI_DEVICE_TABLE(_table) \
const struct pci_device_id _table[] __devinitconst
#endif
+#endifGruß
e9hack
Es sind allerdings außer "__devexit" auch "__devexit_p" Einträge vorhanden. Können diese auch gelöscht werden?
Ja, die muessen dann auch geloescht werden. Das ist aber ein Makro, wenn man es schoen machen will, sollte man also auch die Klammern mit loeschen...
Gruss,
S:oren
Könnten wir bitte zum Thema zurückkehren? Hier geht es um das CI und nicht um HOTPLUG.
Ich hoffe, daß niemand aufgrund der Ausführungen oben auf die Idee kommt, PCIe- (oder PCI-) Karten im laufenden Betrieb zu ziehen oder zu stecken! Dafür ist PC-Hardware nicht ausgelegt.
Außerdem würde ich fast wetten, daß es selbst mit dem Patch oben nicht funktioniert. Niemand macht mit PC-Hardware PCIe-Hotplugging. Alle beteiligten Komponenten sind diesbzgl. ungetestet!
Falls der Patch oben in den Code soll, bitte direkt an den Treiberautor wenden. Falls er akzeptiert wird, kommt er automatisch beim nächsten Merge rein.
CU
Oliver
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!