Hallo, Am Thu, 11 Sep 2003, Philipp Thomas schrieb:
David Haller
[10 Sep 2003 10:44:12 +0200]: Bisher habe ich auch so gut wie *keinen* externen Kerneltreiber gefunden, der sich der vorhandenen Kernel-Makefiles bedient und damit z.B. evtl. zwingend notwendige Compileroptionen nicht verwendet,
Fein. Ich verwende zwar keine externen Treiber, es ist aber beruhigend zu lesen, dass die Programmierer dieser Treiber offenbar ihre Makefiles "sauber" schreiben :)
Was ist daran sauber? Und was daran ist beruhigend?
*huch* *ARGL* *oerks* War ich schon im Halbschlaf? Du hast mich wohl erwischt... *nochmal les* *undnochmal* Interpretiere ich es jetzt richtig: [X] zwingend notwendige Compileroptionen des Kernels sollten von "externen Kerneltreibern" verwendet werden. [X] du hast "so gut wie keinen" (aber doch mind. einen) "externen Kerneltreiber" gefunden, der sich der vorhandenen Kernel-Makefiles bedient, um o.g. Optionen zu uebernehmen. [X] d.h. die meisten "externen Kerneltreiber" verwenden _NICHT_ Kernel-Makefiles um o.g. Optionen zu finden, verhalten sich also fasclh. ('X'e bitte ggfs. entfernen) Falls obige Kreuze korrekt sind nehme ich meine Aussage zurueck und behaupte das Gegenteil. Und fuehle mich in meinem Pessimismus bestaetigt und werde meine intuitive Abneigung gegen "externe Kerneltreiber" weiterhin pflegen... Oh, und wegen mir darfst du gerne ein paar "Delinquenten" nennen :)
Userspace programme, die passende Kernelheader benötigen, sollten, bis auf wenige Ausnahmen, ebenfalls dem jeweiligen Author/Maintainer vor die Füsse geworfen werden.
IMHO flasch! Beispiele:
Das sind die wenigen Ausnahmen. Na gut, ich hätte vielleicht 'bis auf einige Ausnahmen' schreiben sollen :)
Ja. *eg* Was "reine Userspace Programme" angeht: die haben, wie du schon schriebst, sowieso keine Kernel-Header zu verwenden und gehoeren ggfs. schon allein deswegen den Programmieren vor die Fuesse geworfen. Aber es gibt eben Programme, die _brauchen_ diese Header...
- analoge Faelle, die auf HW-Treiber (devices/ioctls) zugreifen muessen, die nicht im Userspace (wie die X11-HW-Treiber?) realisiert sind, z.B. auch Soundkartentreiber...
Userspace Soundkartentreiber? Du beliebst zu scherzen :)
Flascher Begriff, tut mir leid, ich meinte "Programme, die auf ein (sound-bezogenes) Kernel-/Sound-Treiber-Interface zugreifen muessen, sei's wg. allgemeiner Funktionen die evtl. abstrahiert sein sollten oder sei's um $Feature von $Treiber auszureizen... Ich kenne das Sound-/Mixer-Interface des Kernels nicht, ab "wann" man also z.B. fuer ein "Mixer-Programm" wie z.B. kmix oder smix Kernel-Header braucht uebersteigt mein aktuelles Wissen... Was ich mit den "im Userspace realisierten HW-Treibern" meinte, bezog sich eher auf sowas wie die GraKa-Module von XFree86...
Ich habe konkret(!) mit kcmjoy und SDLJoytest die Erfahrung gemacht, dass die "alten" Header mit dem neuen Kernel schlicht und einfach nicht funktionieren[2], eben deswegen habe ich kcmjoy ja auch neu kompilieren wollen.
Die glibc verwendet für solche Fälle Symbolversionen, etwas ähnliches im Kernel und schon wäre Ruhe. Dann würde die Anwendung nämlich sagen: Symbol joydev Version KERNEL_2_2_1 nicht gefunden. Dann würde die Applikation ab einer gewissen Kernelversion einfach aufhören zu laufen.
ACK!!! Das waere eine andere Loesung um ein "*PENG*" beim kompilieren/linken, im "worst case" zur Laufzeit hervorzurufen. Da es das aber nunmal nicht gibt... Ich bin kein "Kernel-Entwickler", aber wenn's darum ginge, versionierte Symbole im Kernel einzufuehren, ich waere dabei -- auch um "Ueberzeugungsarbeit" zu leisten :)
Konkreter Fall: [ ... ]
Fazit aus diesem Fall: Das Problem waren die "alten Header", die lt. dir in /usr/include/{linux,asm} liegen sollten.
Sorry, aber da hast du den falschen Schluss gezogen.
Hm. Warum? Da habe ich nun schon die Bitte, dass du mir das (per PM?) mal erlaeuterst (wenn du magst)... Nein, ich finde beim folgenden von dir (leider) nix... Das sind (mehr oder weniger) nur die mir schon bekannten Argumente, die ich leider einfach (weder praktisch noch logisch/theoretisch) nicht nachvollziehen kann... Mir selbst waere's ja nichtmal unrecht, wenn du recht haettest, dann koennte ich das Thema in aller Stille begraben, ggfs. mein System anpassen (und der Dinge harren die dann folgen *scnr*), und fortan dazu schweigen... Allein...
uebrigens mal interessieren, wie ihr das (z.B. bzgl.
) bei den SuSEs geloest habt, die mit Kernel 2.2.x _und_ 2.4.x ausgeliefert wurden... Ich weiss es nicht und werde das jetzt auch nicht nachforschen.
Schade ;) Da wende ich mich am besten ggfs. wohl mal direkt an Vojtech, oder? Der duerfte das ja zumindest mitbekommen haben, wie man den Konflikt umgangen hat... :)
Aber du solltest dir bewusst sein, dass die glibc abwärtskompatibel in Bezug auf den Kernel ist, sprich Unterstützung für ältere Kernel hat, sofern man dies beim Kompilieren nicht ausschaltet.
Ja. Bin ich. Praktisch geht's also um "Aufwaertskompatibilitaet", und die ist schlicht nicht zu leisten, wenn Kernel-Interfaces (endlich) mal gesaeubert werden... AFAIK steht da ja bzgl. IDE ein "Brocken" an... *harrr* Da faellt mir ein Beispiel ein! Warum muss man z.B. die modutils, e2fsprogs und anderes aktualisieren um $neuen Kernel verwenden zu koennen???
Deshalb *muss* die glibc gegen den neuesten Kernel kompiliert werden, den man verwenden möchte und genau diese Kernelheader gehören in /usr/include/{linux,asm}.
Geht halt in der Praxis nicht. Und ist auch nicht noetig, s.o. IMHO: Entweder ein (Userspace) Programm braucht Kernel-Header, dann muessen diese auch zum Kernel passen (egal ob sich da irgendwo noch die glibc zwischenklemmt, wenn deren (alte) Header nicht passen, dann...)... Andernfalls kann auch die glibc nix ausrichten, wenn z.B. $IOCTL verschwunden ist. Oder das Programm braucht eben keine Kernel-Header -- und sollte sie dann auch (s.o.) gefaelligst auch nicht einbinden, da sind wir uns ja einig :) Wie ich hier tagtaeglich fuer oft > 8h erleben darf laeuft jedenfalls die glibc-2.1.3, die damals gegen nen 2.2.xer Kernel kompiliert wurde wunderbar und stabil (seit nun gut 2 Jahren!!) zusammen mit nem 2.4.x Kernel... Und es sieht fast so aus, als wuerde auch ein 2.6er Kernel mit der glibc laufen... Ich denke da uebrigens ganz pragmatisch: a) ich verwende ein libc-/POSIX-Interface (User-Space), und dazu brauch ich keine Kernel-Header, denn evtl. Anpassungen an das Kernel-API hat hier gefaelligst die libc zu uebernehmen, denn dafuer ist sie ja (u.a.) da, oder b) ich verwende das Kernel-API, da brauche ich dann aber auch das spezifische API, das mir "mein" Kernel auch anbietet, und da helfen mir mehr oder weniger "alte" Header der libc oder aus sonstwelchen Quellen (z.B. Header von irgendwelchen Kernels die zufaellig gerade aktuell waren) genau garnix, da helfen mir nur die Header was, die zu dem Kernel passen, mit dem mein Programm laufen soll... Natuerlich ist das Linux-Kernel-API recht stabil und meist abwaertskompatibel, aber aendern muss und will man es ja, d.h. ueber einen gewissen "Abstand" stellt sich zwangslaeufig ein Konflikt ein. Szenario (rein hypothetisch): [lang, dann gesnippt, als mir das Beispiel modutils/e2fsprogs eingefallen ist] ;) Nimm z.B. die modutils, die e2fsprogs und aehnlich "Kernel-nahes" als Beispiel... Ich kann mir nicht vorstellen, dass du z.B. die e2fsprogs ernsthaft gegen die Header eines 2.2.x-Kernels kompilieren willst, wenn du einen 2.4.x oder gar 2.5.x Kernel verwendest -- und als FS inzwischen nur noch ext3... Was z.B. bei mir auch wunderbar funktioniert, trotz der alten glibc -- die hat _damit_ eben einfach nix zu tun, da sich z.B. 'write(2)' nicht geaendert hat...
Übrigens schaffen es nur zur glibc gehörende Header, auf Biarch-Systemen wie AMD64 zwischen den jeweils nötigen asm Headern zu wählen (asm-x86_64 für den 64 Bit Modus und asm-i386 für den 32 Bit Betrieb).
Das ist ein (neues) Argument[1]... Warum das noetig ist und wieso man die "glibc-Kernel-Header" dann in /usr/include/{linux,asm} will muss ich mal in Ruhe durchdenken... Irgendwie "umschalten" muss man aber wohl. Und wo das passiert... Zum Kernel passen muessen diese Header IMHO aber dennoch...
Dass /usr/include/{linux,asm} nun also wohl ein symlink auf /lib/modules/`uname -r`/build/include/{linux,asm} sein kann/sollte steht auf einem anderen Blatt und waere bei mir hier z.B. noch nicht moeglich.
Das geht nicht (command substitution gibt's nicht in Symlinks :)
<mode type="loriot">Ach?</mode>
und war bestimmt nicht so gemeint.
Bingo. *scnr*, *bg*, *duck* & *run*
Das Programm, welches die echten Kernelheader benötigt, sollte -I/lib/modules/$(shell uname -r)/build/include in CFLAGS packen und schon wäre Ruhe.
Ack. Das sach ich doch die ganze Zeit! *seufz*
Wenn auch auf Umwegen... Denn /lib/modules/`uname -r`/build/include/
ist noch recht neu. Wie sollte man also verfahren, damit z.B. ein
'#include
Noch besser wäre IMO, das solche Programme ihre private Version der nötigen Header mitbringen, wie es z.B. bei den e2fsprogs der Fall ist.
NACK! s.o. Genau das war bei kcmjoy und/oder SDLJoystick so. Die hatten die "alten" Header dabei, die schlicht nicht taten. Mit den passenden Headern laeuft's... -dnh PS: Falls ich nur nerve, sags, ignorier mich etc. pp... [1] sponsort mir jemand (SuSE?) nen Opteron Rechner? Ich taet das gerne testen *scrnr* -- gawk;date;yes;unzip;strip;touch;finger;grabmode;mount;fgrep;find;fish; fold;fsck;fillup;more;true;sync;arch;dumpsect;fluid;dummy;umount;chill; sleep