Wege von config.h nach autoconf.h in den Sources?

[-=Markus=-]

Guten Abend,

ich habe vergangen Woche ein Update meines Systems durchgeführt. Dabei hat es auch ein Update des Kernels von 2.6.18 auf 2.6.22 gegeben. Da ich ein paar persönlihce Dinge für mich kompilieren muss, wollte ich es wie gewohnt mit m-a durchführen. Natürlich hat es nicht funktioniert, da es zwischenzeitlich einen Bruch im Code gegeben hat, wie ich nach dem Update erfahren musste: config.h wurde in den Kernel-Sources entfernt, autoconf.h ist der Ersatz.

Ich habe bei der Fehlersuche im Web gelesen , man solle einen ln -s von config.h auf autoconf.h legen, welches ich auch für ein kleines - unbedeutendes Modul - gelegt habe, und es hat funktioniert.

Meine Frage: Ist das grundsätzlich für alle Modul-Buildings möglich oder sollte man das config.h Problem für alte Sources anders lösen, weil man sonst mit der Methode auf Probleme stösst?

[feldmaus]

Deine Methode von einem alten Kernel auf einen neuen Kernel umzusteigen ist mir absolut neu.

Wenn du deine config übernehmen willst, dann kannst du bequemer Weise einfach in deine
neuen Kernel Sourcen wechseln mit
cd /usr/src/linux
Und machst dann
make oldconfig
Damit er von deinem laufenden alten Kernel die Config in die neuen Kernel Sourcen kopiert.
Neue Optionen die der alte Kernel nicht hat werden von "make oldconfig" erfragt, ob sie und wie sie erwünscht
sind.

Grüsse Markus

[-=Markus=-]

Sorry, war arbeitsmässig eingespannt ...

Es geht nicht um den Wechsel des Kernels an sich. Es geht darum, das es bei der Entwicklung des Kernels einen Bruch gegeben hat, wo die Datei config.h gegen die Datei autoconf.h ausgetauscht worden ist (irgendwann bei 2.6.19 oder so).

Wenn ich z.B. ein Modul compilieren will, mit einer Source die eine config.h erwartet, aber keine findet, weil die ja umbenannt worden ist nach autoconf.h, dann gibt es automatisch Fehlermeldungen und Abbrüche.

Dies habe ich bisher mit ln -s autoconf.h config.h umgangen. Allerdings weiß ich vom Grunde her nicht, inwieweit dies Auswirkungen auf das Ergebnis haben wird. Ist das die gängige empfohlene Methode oder gibt es bessere Wege, eine alte config.h-Source mit einer neuen autoconf.h-Source zu compilieren.

[storm]

Ich kenn das Problem auch, bei mir war damals nur der Versionssprung viel kleiner. Was auch schon Markus sagen wollte ist, dass sich ja nicht nur diese Datei geändert hat, sondern innerhalb des Kernel-Quellcodes eigentlich recht viel. Stichwort: API. Wenn dein Modul mit diesem workaround funktioniert, gut für dich. Aber das heisst nicht, dass es auch vollständig funktioniert; es kann gut sein, dass dir der code bei nächster Gelegenheit um die Ohren fliegt (solange du beim kompilieren und linken keine Warnungen erhälst, solte es gehen). Besser wäre, du schaust dich nach einer neueren, zum Kernel passenden Version deines Moduls um. Oder du änderst den Quellcode (Makefile) soweit ab, dass das Verlinken auf die autoconf.h nicht mehr nötig ist.
Irgendwann in der Zukunft wird (möglicherweise) auch der Punkt kommen, an dem solche einfachen Tricks nicht mehr helfen, weil sich beispielsweise der Aufruf für die Modulinitialisierung ändert. Dann sind auch die nötigen Änderungen im Quellcode deines Moduls größer.

ciao, storm