Melchior FRANZ wrote:
* Philipp Thomas -- Monday 30 April 2001 02:33:
* Melchior FRANZ [Sun, 29 Apr 2001 15:49:37 +0200]:
Ausser, man will's richtig machen. Dann setzt man den Link natuerlich nicht.
Siehe dazu das Kernel README: [...] Falsch! Bis einschliesslich SuSE Linux 7.1 kommen die Header mit dem Kernel, entweder Paket lx_include (nur Kernelheader) oder eben lx_suse (kompletter Kernel). Das heisst, bis einschliesslich 7.1 *muss* der Symlink gesetzt werden. Erst mit der 7.2 wird sich das ändern.
Wovon ich nicht sehr viel halte :)
Glaube mir, ich *weiss* wovon ich rede und folge nicht nur READMEs ;-)
Nein! Natuerlich muss der Link in der =Distribution= derzeit auf die Sourcen des Kernels gesetzt werden, gegen den die libc gelinkt wurde. Und das tut Ihr ja auch. Aber dann darf der Link nicht mehr umgesetzt werden, nur weil man einen neuen Kernel installiert. Das ist erst wieder zu tun, wenn man auch die libc neu kompiliert. Da hat das README schon recht! Nein.
Das Entscheidende ist die Kompatibilität/Konsistenz der zwischen glibc und Kernel geteilten Header. Ob diese auf Kernel oder glibc-Seite liegen, ist von zweitrangiger Bedeutung. Der wesentliche Vorteil diese Header in die glibc aufzunehmen, besteht darin, dass User dann nicht mehr vergessen können die betroffenen Header zu installieren, d.h. die momentan in Folge nicht vorhandener Header auftretenden Kompilierungsprobleme bei nicht vorhandenen Kernelheadern bei Userspace-Programmen treten dann nicht mehr auf.
Wenn mit SuSE 7.2 wirklich endlich Ulrich DREPPERS[1] Fehler behoben wird, und dieser unselige Link von /usr/include/linux auf /usr/src/linux/include/linux endlich der Vergangenheit angehoert, dann gibt's derlei Probleme natuerlich nicht mehr. Glaube mir, diese Probleme wird es auch in Zukunft geben - Nur äussern sie sich dann Anders.
Z.B.: * Viele Kernel-Module ausserhalb des Kernels werden schwerer zu übersetzen sein (Viele greifen direkt auf /usr/include/linux zu). * Wo liegt/Wem gehört linux/autoconf.h (Ist Kernel-Konfig-abhängig und wird von Treiber-Modulen benötigt)? * Werden die betroffenen Datenstrukturen geändert, treten die gleichen Probleme wie bisher auf. * Packaging-Problem: Diese Header sind Bestandteil der Kernelquellen, d.h. glibc-binaries werden in Zukunft mit der Kernelversion gekoppelt werden müssen (Strenggenommen, war dies bisher auch schon der Fall, wirkte sich aber nur selten aus). Da diese Punkte sehr systemnah liegen, ändert sich durch Verschieben der Header auf systemnaher Ebene nahezu nichts, ehe im Gegenteil. Ich bin mir nahezu sicher, dass in Zukunft die Problemem, die gelegentliche Kernel-/Treiber-Übersetzer haben werden dadurch ehe zunehmen werden.
PS: Glaube mir, ich weiss =auch= wovon ich rede. ;-) Ich auch ;-)
Nachdem sich selbst Drepper und Torwalds nicht einigen können, werden auch wir das hier nicht lösen können. Gruss Ralf