Hallo, Am Fri, 05 Sep 2003, Philipp Thomas schrieb:
David Haller
[Fri, 5 Sep 2003 04:53:24 +0200]: (was bei "externen" Kerneltreibern z.B. durchaus zu einem Kernelpanic fuehren koennte!).
Externe Kerneltreiber, die sich darauf verlassen, unter /usr/include/linux bzw. /usr/include/asm die Header des aktuellen Kernels zu finden gehören dem Autor um die Ohren gehauen!
*g*
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 :)
Deswegen musste dort der Link /usr/src/linux zwingend existieren.
Nein! Die Makefiles bzw. configure.{in|ac} gehören entsprechend korrigiert!
Auf "historischen" (ex-)Distri's wie meiner ist's aber schmerzaermer *scnr*
/usr/include/linux und /usr/include/asm sollten also bei aktuellen Distris IMO auf /lib/modules/`uname -r`/build/include/linux bzw. auf /lib/modules/`uname -r`/build/include/asm zeigen. Die Realitaet z.B. bei der 8.2 sieht anders aus, dort sind dies "echte Verzeichnisse" aus "glibc-devel" mit den Headern, gegen die die glibc kompiliert wurde,
Genau wie es IMNSHO sein sollte. Für alles weitere s.o.
IMHO eben gerade nicht. Ich _weiss_[1], dass ich hiermit "die falsche" Meinung vertrete, aber ich werde schlicht das Gefuehl nicht los, dass die Vertreter der "richtigen Meinung" die Situation, in der eben solche Inkompatibilitaeten auftreten koennen, nicht unbedingt kennen... s.u.
Will man also ein Programm schreiben, dass zum Kernel passt darf man nach wie vor nicht /usr/include/{linux,asm} verwenden, denn dort koennen veraltete/unpassende libc-Header rumliegen, sondern man verwendet nun eben statt '-I/usr/src/linux/include' eben '-I/lib/modules/`uname -r`/build/include' was durchaus ein Fortschritt sein _koennte_,
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:
- 'kcmjoy' aus KDE 1.x (und spaeter?)
- SDLJoytest
- xawtv (!) und andere v4l basierte...
- 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...
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.
Konkreter Fall:
- ich wollte kcmjoy meines KDE 1.1.2 verwenden. Nein, ich will kein
KDE3. Ich verwende KDE sowieso nicht mehr. Danke der Nachfrage.
- kcmjoy war seit dem Kernelupdate auf 2.4.x dysfunktional (zur
Laufzeit!)
- eine "naive" Rekompilierung lief sauber durch (Kein Fehler beim
kompilieren/linken!)
- Da kcmjoy aber die alten joystick-Header "dabei hatte" (die gleichen
Header eines 2.2.x Kernels, wie sie (lt. z.B. dir, Linus u.a.) in
/usr/include/{linux,asm} haetten liegen sollen (ich habe die alten
Header zum Vergleich angesehen!), war kcmjoy _immernoch_ genauso
dysfunktional wie zuvor -> Fehler zur Laufzeit!
- Da bei mir seit langem /usr/include/{linux,asm} symlinks auf
/usr/src/linux/include/{linux,asm} sind fiel mir auf, dass diese
Header nicht verwendet wurden, sondern eben die alten.
- Ich zwang[3] kcmjoy dazu, die aktuellen Kernel-Header (also
"Kernel-Space" Header) zu verwenden (wo diese liegen ist letztlich
irrelevant), und rechnete mit Fehlern beim Kompilieren/Linken.
- aber ich hatte Glueck, es lief sauber durch und "TADA!" seitdem
laeuft kcmjoy wieder, wider Erwarten gab es auch zur Laufzeit keine
Konflikte.
- NUR(!) durch den Austausch der "glibc-Kernel-Header" gegen die
Kernel-Header meines aktuellen Kernels wurde auf "wundersame Weise"
aus eine dysfunktionalen User-Space(!) Anwendung eine funktionale
Anwendung...
Fazit aus diesem Fall: Das Problem waren die "alten Header", die lt.
dir in /usr/include/{linux,asm} liegen sollten.
Fazit: Wir sind uns ja alle einig, _dass_ zu Konflikten kommt. Die
Frage ist also doch die _wann_ man Konflikte bemerkt. Und mit "alten"
Headern in /usr/include/{linux,asm} [4] merkt man die eben spaeter,
als wenn man die Header des "Ziel-Kernels" verwendet, naemlich erst
zur Laufzeit, wohingegen man mit aktuellen Headern Konflikte schon
beim kompilieren, beim linken oder im schlechtesten Falle _auch erst_
zur Laufzeit bemerkt.
Und jetzt postulieren wir mal eine andere Anwendung als kcmjoy, die
nicht nur schlicht dysfunktional waere, sondern z.B. einen kernel-panic
ausloesen wuerde[5]... Wann will man also einen Konflikt bemerken? Na?
Einfach, oder?
Und wenn die glibc nicht mehr zum Kernel passt hat man eh verloren.
Das Argument, dass die "Kernel-Header" (sic!) also die sein sollten,
gegen die die verwendete glibc kompiliert wurde, ist IMHO an den
Haaren herbeigezogen und irrelevant, nein, sogar schlicht Unfug. Denn
wenn die glibc nicht zum Kernel passt und nicht mehr funktioniert,
dann funktioniert fast gar nix mehr (wie ich mal unfreiwillig erfahren
durfte), da helfen einem irgendwelche Header genau garnix.
Jedenfalls, das Thema hatten wir hier IIRC sogar schonmal, wir konnten
uns damals IIRC ebenfalls nicht einigen, aber damals hatte ich noch
nicht obigen konkreten Fall, der mich in meiner gegensaetzlichen
Meinung so bestaerkt hat.
Wir sind damals IIRC noch weiter ins Detail gegangen, aber es blieb
IIRC dabei, dass man, wenn man gegen die von der glibc mitgelieferten
Header kompilierte, evtl. Konflikte mit dem tatsaechlich laufenden
Kernel auch im Idealfall erst zur Laufzeit detektieren konnte -- so
"sauber" dieses Vorgehen ansonsten auch sein mag. Ich setze hier also,
gerade wg. obiger Erfahrung, ganz simple Prioritaeten... Ich will
Fehler/Konflikte schlicht "so frueh wie moeglich" bemerken koennen.
Ich lasse mich hierbei uebrigens gerne widerlegen. Aber ich bin so
respektlos, so wichtige Meinungen wie deine, Linus' und anderer als
"falsch" zu betrachten, solange bis mir jemand diese Meinungen mal
schluessig belegt (und z.B. erklaert, warum '"glibc-Kernel-Header" in
/usr/include/{linux,asm}' (auch in z.B. obigem Fall) besser ist als
'"/usr/include/{linux,asm} zeigen auf die Header des aktuellen
Kernels"').
Ich _will_ doch gerade -- wenn es denn schon mal *PENG* macht, weil
Anwendung, glibc und Kernel nicht mehr zueinander passen -- dass es so
frueh wie moeglich *PENG* macht, also moeglichst schon beim kompilieren
oder linken... Und genau dies wird IMHO durch "glibc-Kernel-Headern" in
/usr/include/{linux,asm} sabotiert..
Nochwas: jemand wie AFAIK du, der eher "mit konsistenten Distributionen"
agiert, der wird ueber Sachen wie oben natuerlich eher nicht stolpern...
Und _dann_ ist deine Meinung natuerlich soweit nachvollziehbar, da es
dann ja auch nicht zu solchen Konflikten kommt... Mich wuerde dabei
uebrigens mal interessieren, wie ihr das (z.B. bzgl.