Hallo, ganz allgemein ein paar Infos: 1) Es gibt nur ein /usr/src/linux, aber das ist bei mir immer nur ein Link. Also habe ich unter /usr/src in etwa folgende Situation: linux -> linux-2.4.20 linux-2.4.20/ linux-2.4.18/ Dann kann ich per Umsetzen des Links jederzeit hin und her switchen. Wichtig sind hier evtl. noch die Module. Wenn die Kernel unterschiedliche Versionen haben, geht es ganz gut, aber ansonsten kannst Du hier auch noch Probleme kriegen, wenn zwei Kernel im gleichen Verzeichnis Ihre Module liegen haben ... Und was den Kernel angeht: Du kannst meherere Kernel bei Dir installiert haben und Du gibst im GRUB oder LILO an, welchen Kernel er booten soll. /boot/vmlinuz bzw /vmlinuz ist wohl der Standard-Kernel, der normalerweise genommen wird. Aber Du kannst noch einen /boot/vmlinuz-safe oder so haben. Nur eben musst Du dann z.B. im LILO einen entsprechenden Eintrag in die Config mit einbauen. Ansonsten kannst Du über die SuSE-CDs aber Dein System auch starten. Ich habe keine original-CDs, aber bei der CD zur Netzwerkinstallation kommt man auch in ein Menü, wo man das installierte System starten kann. Mit den besten Grüßen, Konrad -- Zufallssignatur 2: Problem mit SuSE Linux? Schon in der SDB nach Hilfe gesucht? http://sdb.suse.de/sdb/de/html/

Al Bogner schrieb am Samstag, 30. August 2003 19:19:

Am Samstag, 30. August 2003 19:02 schrieb Konrad Neitzel:

Hallo,

Auch klar und ich weiß auch, dass ich ohne die Kernel-Sourcen zur Not auskomme. Aber mir geht es um eine elegantere Lösung mit dem Mantel-Kernel als einfach darüber schreiben.

Eigentlich benötigst Du nur kernel-source-2.4.21-58.i586.rpm. Die verden dann mittels rpm schon in das Verzeichnis /usr/src/linux-2-4-21.SuSE installiert werden, also kein Überschreiben der anderen Kernel-Quellen. Gruß Stefan

Konrad Neitzel schrieb:

1) Es gibt nur ein /usr/src/linux, aber das ist bei mir immer nur ein Link. Also habe ich unter /usr/src in etwa folgende Situation:

linux -> linux-2.4.20 linux-2.4.20/ linux-2.4.18/

Dann kann ich per Umsetzen des Links jederzeit hin und her switchen.

Der Link ist voellig unwichtig. Entferne ihn, und Dein System wird noch genau so funktionieren. Er ist zum Konfigurieren, Compilieren und Installieren eines Kernels nicht noetig. Auch externe Module sollten sich compilieren lassen ohne diesen Link, wenn das Makefile der Module korrekterweise den Link /lib/modules/`uname -r`/build auswertet und nicht den Link /usr/src/linux. Er kann in manchen (eher seltenen) Situatio- nen noch gebraucht werden, ansonsten wird aber zu viel Trara um diesen Link gemacht. Jede Distribution kommt mit zwei Sets von Kernel-Headern daher: die System Kernel Headers und die Kernel Source Headers. Die System Kernel Headers sind die Header-Dateien, die vom System wirklich benutzt werden. Jedes Programm aus dem sog. User-Space (also jedes Anwendungsprogramm) wird mit Hilfe dieser Header compiliert. Ueblicherweise liegen diese Header-Dateien in /usr/include/asm und /usr/include/linux. Diese Dateien sollten nie ersetzt werden, ausser bei einem Update der C Bibliothek (aber das ist selbst fuer Experten keine einfache Aufgabe und jedem normalen Anwender kann man vom Updaten der glibc nur ab- raten!). Diese Header-Dateien koennen mit vielen unterschied- lichen Kerneln genutzt werden (es gibt Kompatibilitaets-Code) und sind Teil des glibc Paketes. Sie werden normalerweise ueber das Paket glibc-devel installiert. Die Kernel Source Headers sind Teil der Kernel-Quellen. Diese Header-Dateien sollten im Quellcode von Anwendungsprogrammen _nie_ direkt eingebunden werden. Bei aelteren Linux-Distribu- tionen waren /usr/include/linux und /usr/include/asm nur sym- bolische Links auf Unterverzeichnisse innerhalb der Kernel- Quellen in /usr/src/linux und enthielten somit keinen eigenen Satz von Header-Dateien. Deswegen musste dort der Link /usr/src/linux zwingend existieren. Das ist mittlerweile eigentlich bei allen Distributionen behoben. Die Kernel Source Headers werden verwendet, um den Kernel selbst oder Kernel-Module zu compilieren. Das Makefile zum Compilieren von externen Kernel- Modulen sollte daher nicht darauf vertrauen, dass der Link /usr/src/linux existiert und korrekt ist (und damit die Header- Dateien im Unterverzeichnis ./include der Kernel-Quellen gefunden werden), sondern stattdessen eben den Link /lib/modules/`uname -r`/build auswerten. HTH, Thomson

On Fri, 2003-09-05 at 04:53, David Haller wrote:

Hallo,

On Sun, 31 Aug 2003, Thomas Hertweck schrieb:

...

Konrad Neitzel schrieb:

/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.

Sorry David, aber das ist ... . /usr/include/linux und /usr/include/asm sind Bestandteil der "System-Headers", die wiederum die User-API eines Systems darstellt. /lib/modules/*/build/* hingegen bildet die API des korrespondierenden Kernels.

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, d.h. die Probleme, die mit einem anderen Kernel auftreten koennen, koennen erst zur Laufzeit bemerkt werden. *seufz* Ja.

Das Problem verlagert sich also nur von einem symlink (/usr/src/linux) auf einen anderen (automatisch pro Kernel erstellten, eben auf /lib/modules/`uname -r`/build), was durchaus als Fortschritt angesehen werden kann... Ja.

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_, falls der Admin mal sein /usr/src/linux nicht gepflegt hat -- andererseits ist es ein Rueckschritt, da es den Admin noetigt, den Kernel zu booten, fuer den kompiliert werden soll[3], mit /usr/src/linux musste er nur diesen symlink auf die passenden Kernelquellen umbiegen... Jein.

Richtig ist, /lib/modules/`uname -r` nimmt die Header des laufenden Kernels, /lib/modules/<kernel-version> hingegen die Header des Kernels der in <kernel-version> angegeben ist. Mit anderen Worten, das Makefile eines Kernel-modules sollte so geschrieben sein, dass es per default `uname -r` verwendet, sich dieser Wert aber überschreiben lässt. Findest Du in einem GNUmakefile z.B. dieses: KERNDIR=/lib/modules/$(shell uname -r) kannst Du es (sofern das GNUmakefile sauber geschrieben ist) mit gmake KERNDIR=/lib/modules/2.4.16-dnh oder ä. überschreiben.

Das Grundproblem aber bleibt also. Nur leider scheinen die relevanten (Linus, U. Drepper u.a., Mantel?) Leute eben anderer Ansicht als ich.

Fazit: ich werde auch weiterhin nicht drumrumkommen, wie vor 3 Jahren symlinks zu legen und umzubiegen... Siehe oben.

[3] was beim cross-compile unmoeglich sein kann! Sachlich falsch. Es besteht kein Bedarf zu "rebooten".

Ralf

On Wed, 2003-09-10 at 08:52, David Haller wrote:

Hallo,

[sorry fuer die Verspaetung]

Am Fri, 05 Sep 2003, Ralf Corsepius schrieb:

...

On Fri, 2003-09-05 at 04:53, David Haller wrote:

...

On Sun, 31 Aug 2003, Thomas Hertweck schrieb:

...

Konrad Neitzel schrieb:

...

/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.

Sorry David, aber das ist ... .

Ja? Was? Mist? Unfug? Faslch? Zu kurz gedacht? :) In der ursprünglichen Fassung der Mail stand da mal "Bockmist", später auf "Quatsch" umgeändert, dann auf "Unfug" abgeschwächt. Schliesslich war mir alles zu hart, und ich zog es vor "..." zu verwenden ;-)

Ralf

Moin! David Haller wrote:

On Sun, 31 Aug 2003, Thomas Hertweck schrieb:

...

[.../usr/src/linux als Link...] Der Link ist voellig unwichtig. Entferne ihn, und Dein System wird noch genau so funktionieren. Er ist zum Konfigurieren, Compilieren und Installieren eines Kernels nicht noetig. Auch externe Module sollten sich compilieren lassen ohne diesen Link, wenn das Makefile der Module korrekterweise den Link /lib/modules/`uname -r`/build auswertet und nicht den Link /usr/src/linux. Er kann in manchen (eher seltenen) Situatio- nen noch gebraucht werden, ansonsten wird aber zu viel Trara um diesen Link gemacht.

Bei aktuellen Distri's mit Kernel >= 2.4.0 und glibc >2.2: Ja. Sonst: Nein.

Ja, wie ich schrieb: frueher war der Link noetig, heute bei aktuellen Distris ist der Link nicht mehr noetig und kann ganz fehlen.

[...]

/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.

Sorry, aber Du liegst hier daneben. Du musst unterscheiden zwischen User-Space und Kernel-Space. /usr/include/linux und /usr/include/asm kommen aus dem User-Space, das Ver- zeichnis /lib/modules/`uname -r`/build/include/linux bzw. /lib/modules/`uname -r`/build/include/asm ist eindeutig Kernel-Space. Es hat schon Sinn, das zu trennen, was mit dem, was Du hier vorschlaegst, ad absurdum gefuehrt wuerde. Ich habe gerade vor kurzem einen entsprechenden Abschnitt im Buch "Linux Kernel-Programmierung" gelesen und Du fin- dest entsprechende Hinweise auch auf kernelnewbies.org un- ter FAQ.

[...] Will man also ein Programm schreiben, dass zum Kernel passt darf man nach wie vor nicht /usr/include/{linux,asm} verwenden,

Kernelsourcen sollten _nie_ User-Space Header einbinden. Du wirst beim Compilieren der Kernels auch die Option -nostdinc vorfinden, d.h. die Standard-Include-Pfade des Compilers werden explizit abgeschaltet! AFAIK gibt es genau einen einzigen Treiber im gesamten Kernelsource, dem es erlaubt wurde, auf System-Ressourcen zurueckzu- greifen, weil es dort nicht anderst zu loesen war.

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_, falls der Admin mal sein /usr/src/linux nicht gepflegt hat -- andererseits ist es ein Rueckschritt, da es den Admin noetigt, den Kernel zu booten, fuer den kompiliert werden soll[3], mit /usr/src/linux musste er nur diesen symlink auf die passenden Kernelquellen umbiegen...

Wenn `uname -r` ausgewertet wird, muss man rebooten, aber i.d.R. laesst sich das ueberschreiben und man kann sehr wohl Module fuer einen Kernel compilieren, der nicht gebootet ist. Ob ich nun einen Symlink umbiege, wie Du es sagst, oder ob ich per Variable oder im Makefile das richtige Verzeichnis fuer die Kernel-Header auswaehle, wo ist da der Unterschied?

Das Grundproblem aber bleibt also. Nur leider scheinen die relevanten (Linus, U. Drepper u.a., Mantel?) Leute eben anderer Ansicht als ich.

Ich denke, Du bist evtl. mit Deinem System und Deinen Ansichten vielleicht nicht mehr ganz aktuell :-))

PS @ Thomson: war im Urlaub, sorry, dass ich mich nicht abgemeldet habe... kannst du mir das nun aktuelle .tex mailen?

Es gibt kein .tex mehr. Aktuelle Version ist online unter http://www.thomashertweck.de/kernel.html. Gruesse und welcome back! Thomson

David Haller schrieb:

[...] Das Andersherum aber ist mein Anliegen: Userspace Programme (keine Module) muessen teilweise wg. Treiber-Header einbinden. Und diese Header _muessen_ zum Kernel passen. [...]

Ich compiliere ja einige Software selbst, aber so etwas ist mir noch nicht untergekommen. Hier laeuft auch neben Kernel 2.4 zu Testzwecken ein Kernel 2.6 - aber auch da gab es bis- her keine Probleme, sowohl Programme aus dem User-Space als auch Module o.ae. zu uebersetzen. Wenn Probleme auftauchten, dann hatte das nichts mit der in diesem Thread angesproche- nen Problematik zu tun. Vielleicht bin ich bisher einfach nicht auf die richtigen Programme gestossen - normale Pro- gramme aus dem User-Space, die Kernel-Header einbinden, sind jedenfalls IMHO mit extremer Vorsicht zu geniessen... CU, Th.

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. ) bei den SuSEs geloest habt, die mit Kernel 2.2.x _und_ 2.4.x ausgeliefert wurden... 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. Achso, meine Testplattform hier: $ uname -a Linux slarty 2.4.16-3 #20 Sat Nov 30 16:57:22 CET 2002 i686 unknown $ cat /etc/SuSE-release | head -n 1 SuSE Linux 6.2 (i386) $ /lib/libc.so.6 | head -n 1 GNU C Library stable release version 2.1.3, by Roland McGrath et al. $ rpm -q --queryformat "%{name}-%{version}-%{release} %{distribution} %{buildtime:date}\n" -f /lib/libc.so.6 shlibs-2.1.3-65 SuSE Linux 6.4 (i386) Fri 24 Mar 2000 07:02:27 PM CET $ rpm -qvl libc | grep 'include/\(linux\|asm\)' | cut -b40- 29 Mar 24 2000 /usr/include/asm -> ../src/linux/include/asm-i386 26 Mar 24 2000 /usr/include/linux -> ../src/linux/include/linux $ ls -l /usr/include/{linux,asm} /usr/src/linux | cut -b40- 24 Mar 21 2002 /usr/include/asm -> ../src/linux/include/asm 26 Mar 21 2002 /usr/include/linux -> ../src/linux/include/linux 12 Mar 21 2002 /usr/src/linux -> linux-2.4.16 Leider weiss ich nicht, mit welchem Kernel diese libc kompiliert wurde... Und obendrein wurde diese glibc ueber ein "Chaos" drueberinstalliert, das von einem versauten Versuch eine glibc-2.2 zu kompilieren hinterlassen wurde... Jedenfalls laeuft's seit dieser Rettungsaktion wieder stabil: $ rpm -q --queryformat "%{installtime:date}\n" -f /lib/libc.so.6 Thu 15 Mar 2001 05:03:51 AM CET Ja, ich _weiss_, dass bei mir Kernel <-> libc Konflikte "vorprogrammiert" sind, aber eben darum geht's ja... -dnh PS: in der RPM-Datenbank sind noch Reste des libc-Chaos ;) U.a. waren RH-RPMs beteiligt ;) Und rpm spuckt z.B. noch folgendes aus: $ rpm -q --queryformat "%{name}-%{version}-%{release} %{distribution} %{installtime:date}\n" -f /lib/libc.so.6 glibc-2.1.3-14 BlueSky Thu 06 Apr 2000 06:56:00 AM CEST shlibs-2.1.3-65 SuSE Linux 6.4 (i386) Thu 15 Mar 2001 05:03:51 AM CET Keine Ahnung was/woher das "BlueSky" stammt... *g* Hm. Da lass ich doch glatt mal ein 'rpm -e --justdb glibc-2.1.3-14' laufen. Das war ueberfaellig, ich weiss auch nicht, wieso ich das nicht schon vor Jahren gemacht habe :) Nu ist's besser :)) PPS: Mit cross-compiles habe ich (mangels anderen Plattformen) praktisch keine Erfahrung, ich sehe aber keine zusaetzlichen Hindernisse... [1] den Flamewar koennen wir uns also sparen... [2] wg. der Umstellung auf /dev/input usw. [3] wie genau weiss ich nicht mehr... Jedenfalls wurden dann die Header meines aktuellen Kernels verwendet. [4] und falls hier /usr/include/{linux,asm} falsch sein soll, wozu waere /usr/include/{linux,asm} dann noch gut?!?!?! Wenn man "hier" dies nicht verwenden soll, dann kann man /usr/include/{linux,asm} auch gleich komplett weglassen! [5] warum auch immer -- mit HW-Treiber sollte das recht einfach gehen... -- q: If you were young again, would you start writing TeX again or would you use Microsoft Word, or another word processor? a: I hope to die before I *have* to use Microsoft Word. -- Harald Koenig asking Donald E. Knuth

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 wer hat das {,} im symlink expandiert?</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 ' in den e2fsprogs klappt??? CFLAGS += -I???? Welches Programm, dass die echten Kernelheader _nicht_ benoetigt, sollte /usr/include/{linux,asm} bzw. "" "" ueberhaupt verwenden??? Welches Programm, das die echten Kernelheader benoetigt, sollte /usr/include/{linux,asm} bzw. "" "" verwenden??? Und welche Kernelheader sollte dieses Programm dann dort vorfinden??? Welches Programm, braucht die Kernelheader, gegen die die glibc irgendwann[tm] mal kompiliert wurde? Etwa irgendwelche, im besten Falle vom API passende, halbwegs aktuelle, im weniger optimalen Falle aber irgendwelche veralteten glibc-kernel Header? Dass die "glibc-Kernelheader" nicht immer aktuell sein _koennen_, darueber muessen wir ja hoffentlich nicht diskutieren... Dass diese Header evtl. im Quellcode-Baum der glibc auftauchen koennen/sollten ist ein anderes Thema, da die glibc selbst "nur" ein Wrapper um das Kernel-API ist, also eines der "Programme" ist, die die (aktuellen!) Kernel-Header brauchen... Wozu braucht's also /usr/include/{linux,asm} ueberhaupt, wenn diese _nicht_ die Kernelheader des aktuell laufenden Kernels enthalten bzw. auf die echten Kernelheader zeigen (in Anbetracht o.g. Argumente, das veraltete Header genau garnix bringen)??? (dass da ggfs. passend verlinkt werden muesste lass ich mal aussen vor, da das ein triviales Detail waere, das hiermit also irrelevant ist.) Nun, IMHO kann man dann die Geschichte einfach abkuerzen (wie SuSE es ja auch zeitweise praktiziert hat) und /usr/include/{linux,asm} schlicht auf die passenden Header des aktuellen Kernels zeigen lassen.

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

Al Bogner wrote:

Ich will mir ein Multikernel-System zum Testen des KT400A-Chips bauen und mir dabei den Ast nicht absägen und auf jeden Fall die safe-settings von 2.4.20 booten können. Außerdem möchte ich auf einem anderen PC testen, ob jetzt die Nvidia-Treiber-Einbindung funktioniert.

Ich habe alien noch nie verwendet.

Meinst du man kann von ftp://ftp.suse.com/pub/people/mantel/next/RPM/kernel-source-2.4.21-58.src.rpm mit alien eine tgz-Datei erstellen? Letztlich geht es mir nur darum, dass die vorhandenen SuSE-Sourcen bzw. der Kernel nicht überschrieben wird.

Das ist ein src.rpm, das holst Du und installierst es (rpm -i). Damit wird noch kein kernel gemacht. Dann findest Du die Dateien in /usr/src/packages/... . In .../SOURCE ist ein .tar.bz2 (Kernel, den Du suchst) und die patches von Suse. In .../SPECS ist die spec-datei, mit der Du dann ein kernel-rpm daraus bauen könntest. Schau es dir einfach mal an. Wenn Du fragen dazu hast (http://www.tu-chemnitz.de/linux/Dokumentation/RPM/) find ich sehr nett gemacht. Für das installieren von kerneln schau mal in die kernel-doc von Thomas Hertweck (http://www.thomashertweck.de/).

Da gibt es auch noch ein ftp://ftp.suse.com/pub/people/mantel/next/RPM/k_athlon-2.4.21-58.src.rpm mit 312k. Wofür ist denn das?

Das ist nur das spec-file um athlon kernel zu bauen. Als Basis brauchst Du die kernel-source's. -- Andreas