Am Sam, 09 Feb 2002 schrieb David Haller:
Hallo Waldemar,
On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:
From the keyboard of Dieter, [...] Das wird Probleme geben. Etliche Anwendungen suchen nach /usr/src/linux/include/, Wenn dann nicht der Link auf die Kernelversion mit den entsprechenden Include-Dateien gegeben ist ... Du kannst dir sicher vorstellen was dann geschieht.
Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine.
Da nicht. Aber sehr wohl in /usr/include/linux und /usr/include/asm. Und bei mir ist, seit 2.2.10 (aber ich hab's seit 2.0.35 so gehalten) ist (rechte/datum gekuerzt)
# ls -alF /usr/include/linux /usr/include/asm /usr/src/linux /usr/include/asm -> ../src/linux/include/asm/ /usr/include/linux -> ../src/linux/include/linux/ /usr/src/linux -> linux-2.4.16/
War ja auch lange bei den Distributoren so gehalten und seit 7.2 ist SuSE wieder davon abgegangen.
Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC.
Mag sein. Aber ich wuerde Linus da widersprechen. Warum?
Vielleicht solltest Du das mal auf der lkml mit ihm besprechen, würde mich interessieren, was dabei rauskommt.
Szenario:
Schritt 1: libc-foo wird gegen kernel-2.2.x kompiliert, und verwendet also das kernel-api-2.2.x. Soweit, so gut, keine Diskussion. Ob die Header dabei die vom Kernel sind, oder bei der libc "dabeiliegen" ist irrelevant.
ACK.
Schritt 2: Updates...
a) Update des Kernels, z.B. auf 2.4.x. libc-foo verwendet aber weiter kernel-api-2.2.x. -> Was wenn "syscall x" verschwindet? Da helfen die ach so tollen header von kernel-api-2.2.x die bei der libc dabei waren auch nicht weiter... Abhilfe: Vielleicht gibt's in den kernel-2.4.x headern ein kompatibilitaets-api Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} Das (veraltete) kernel-api der libc zu verwenden, wenn der kernel das api nicht mehr unterstuetzt ist IMO eine "Bad Idea"[tm].
Ich gebe Dir recht, daß es ein Problem sein könnte, wenn der Kernel in den original Headeren deklarierte Aufrufe nicht mehr unterstützt, gehe aber mal davon aus (ohne es belegen zu können), daß der weitgehend abwärtskompatibel gehalten wurde. Aber das Problem ist doch hier die Aufwärtskompatibilität. Wenn Du die Header des aktuellen Kernels als Includes verwendest, sind dort u.U. Funktionen deklariert, die in der glibc nicht unterstützt sind, das bedeutet es wird einen Linker-Fehler geben. Wenn Du jetzt nicht weißt, woran das liegen könnte, wirst Du als Programmierer doch bekloppt. IMHO gibt es keine andere Alternative, als beim arbeiten mit Bibliotheken und Include-Dateien, die exakt zueinander passenden Versionen zu verwenden.
b) Update der libc auf Version bar Verwendet das api von kernel-<auchegal> Folgerung: wenn libc-bar auf dem api von kernel-2.4.x beruht, macht's "PENG" wenn man noch kernel-2.2 verwendet und ein in 2.2 nicht vorhandenere syscall aufgerufen wird. Abhilfe: Kernelupdate/libc downdate. Nichts was man gerne mal so eben machen wollte. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} damit solche Probleme (nicht vorhandene syscalls) wenigstens beim kompilieren schon erkannt werden, und nicht erst zur laufzeit. Das (zu neue) kernel-api der libc zu verwenden, wenn der kernel das api nicht unterstuetzt ist IMO eine "Bad Idea"[tm].
Gebe Dir recht, das es wohl keine gute Idee ist, eine libc zu verwenden, die gegen einen neueren Kernel, als der von einem selbst eingesetzte, kompiliert wurde, zu verwenden.
c) beides updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} da nun auch die libc das passende api verwendet
Geht aber nur, wenn Du nur eine Kernel-Version parallel verwendest. Ist bei mir nicht unbedingt so.
d) nichts updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} siehe c).
Fazit: Linus liegt IMO falsch.
IMHO nicht.
Ich verwende hier eine glibc-2.1.3 (gegen 2.2.10 kompiliert!) und Kernel 2.4.16 und kann mir beim besten Willen nicht vorstellen, dass ein verwenden des 2.2.10er Kernel-apis alles gut gehen wuerde.
Verwende eine lib 2.1.? gegen Kernel 2.2.16 kompiliert und seitdem einige 2.2er und 2.4er Kernel (mittlerweile 2.4.14) und /usr/src/linux zeigt immer auf die Includes des 2.2.16er Kernels -> nie Probleme. FYI: Linus Meinung dazu findest Du hier: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html Aus dem Posting geht IMHO auch hervor, daß der Kernel abwärtskompatibel gehalten wird. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen