On Tue, May 01, Ralf Corsepius wrote:
Die entscheidende Fragen wären, * wohin /usr/include/[linux|scsi|asm] und /usr/src/linux zeigen, bzw. was sie beinhalten.
/usr/include/scsi kommt, wie schon immer, aus der glibc, die andern beiden Verzeichnisse haben Dich nicht zu interessieren. Wenn Du sie doch für ein Userland-Programm brauchst machst Du etwas falsch.
* wie die Config-Header (linux/config.h, linux/autoconf.h) unter /usr/include/[linux|..] behandelt werden
Die haben da gar nichts verloren. Wenn Dein Programm die braucht machst Du wieder etwas falsch. Ein Userland-Programm sollte niemals auf eine spezielle Kernel-Konfiguration angepaßt sein, sondern mit jeder klarkommen.
Z.B. wäre ein mit der glibc kommendes /usr/include/linux/autoconf.h ohne jeglichen sinnvollen Inhalt, da kein Zusammenhang zum verwendetet Kernel besteht. Da autoconf.h von config.h included wird, config.h aber z.B. auch von fs.h included wird, wären auch diese sinnlos. D.h. die Header
Was juckt Dich linux/fs.h ? Wenn Du die brauchst ist Dein Programm buggy, so einfach ist das. Schau Dir z.B. mount an, wie einfach es auch korrekt geht. Und das sogar noch für Filesysteme, die Du nur mit der Benutzung von linux/fs.h heute gar nicht mehr mounten könntest.
des Kernels mit der glibc2 zu bundeln, mit der die glibc2 übersetzt wurde, ist _NICHT_ ausreichend, sondern bedarf weiterer Massnahmen (==Änderungen an den Kernelheadern). Die Aussage "Es müssen die Kernelheader mit der die glibc übersetzt wurde in die glibc-Header kopiert werden" ist somit schlichtweg falsch.
Nein, Dein Programm ist buggy.
Damit eng verwandt: gcc -I/usr/src/linux/include -o file.o -c file.c (Wird in den Makefiles einiger externer Modulen verwendet). Fehlt ein Header in /usr/src/linux/include, wird der aus /usr/include verwendet. Fehlt /usr/src/linux/include völlig, z.B. weil keine Kernelquellen installiert sind, und wird ein externes Kernelmodul übersetzt, passiert dann alles mögliche. Bis hin, dass Module mit völlig falschen Symbolen, scheinbar fehlerfrei kompiliert werden (Würde mich nicht überraschen, wenn etliche der NVidia-Probleme genau darauf zurückzuführen wären. Der gestrige Thread zum Thema NVidia + 2.4.2 riecht förmlich danach.)
Sorry, aber das ist nonsens. Wenn die Module richtig programmiert sind brechen sie ab, wenn kein /usr/src/linux existiert, ansonsten sind sie buggy und gehören gefixt.
Ein weiteres Problem: Externe Kernelpatches und korrespondierende Userspace-Programme (Beispiel aus der Vergangenheit: ReiserFS). Hier wird es dann notwendig, Header mehrfach zu behandeln, sobald diese Kernelpatches auf Kernelheader zugreifen (z.B. fs.h) und Userspaceprogrammen neue Features zur Verfügung stellen.
Nochmal: Userland-Programme dürfen keine Kernel-Headers includen.
=> D.h. aus meiner Sicht verlagert ein Verschieben der Kernelheader die Probleme nur, löst das Problem aber nicht wirklich, da nach wie vor genügend Raum für Inkonsistenzen zw. glibc und kernel bleiben.
Nein, nur buggy Programme fallen auf die Nase. Userland-Programme dürfen keine Kernel-Header includen, so einfach ist das. Da sind sich alle einig.
Insbesondere sehe ich nicht, wie das z.B. die vor einiger Zeit aufgetretenen scsi/sg.h-Inkompatibilitäten (Vgl. Documentation/scsi-generic.txt) u.ä. behoben oder gar vermieden hätte.
Gar nicht, weil diese Programme nur mit einem speziellen Kernel liefen und, sobald ich den ausgetauscht habe, auch nicht mehr gingen. Das beste Beispiel für ein broken Interface und der beste Grund dafür, niemals Kernel-spezische Header Dateien zu nehmen, sondern generische Wrapper, die mit allen Kernel laufen. Tschau, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B