Kernel 2.4.17 und Sound

Axel Heinrici

5 Feb 2002 5 Feb '02

22:48

Hi Ich arbeitete mit einer 7.3er Suse mit Kernel 2.4.10 (SuSE-standart-Kernel). Der säuft allerdings gelegentlich ab. YaST2 (ist nicht so erstaunlich) aber auch Gimp oder Staroffice können den Abschiessen. Dann reagiert nichts mehr. Auch NUM-Lock und Netzwerk nicht. Ich habe heute mal einen 2.4.17er Kernel von ftp.uk.linux.org kompiliert und auch erfolgreich damit neu gebootet. Dabei habe ich, die configdatei vom alten Kernel in das neue Quellenverzeichnis kopiert und erstmal nur marginale Änderungen vorgenommen, um keine Überraschungen zu erleben. --- Ok ich musste erstmal die Reiser-FS Unterstützung hart reinkompilieren (sonst Kernel panic). Aber eines will natürlich trotzdem nicht mehr so richtig. Ich benutze einen soundblaster live. Beim booten erscheint in der Konsole die meldung emu10k1modprobe: can't locate module snd-card-emu10k1 . In /lib/modules/2.4.17/kernel/drivers/sound/emu10k1 gibt es ein emu10k1.o genauso wie in dem entsprechenden Verzeichnis beim alten2.4.10er Kernel. Auch ein modprobe emu10k1 gibt keine Fehlermeldung raus und der Sound funktioniert dann auch wieder. Was ist da los? Ich kenne mich leider mit den Lademechanismen für Module nicht besonders aus. Gruß Axel

Show replies by date

Michael Raab

5 Feb 5 Feb

23:23

Hallo, at Tue, 5 Feb 2002 23:48:30 +0100 Axel Heinrici wrote:

...

Ich benutze einen soundblaster live. Beim booten erscheint in der Konsole die meldung emu10k1modprobe: can't locate module snd-card-emu10k1 .

Das könnte an den Einträgen in der modules.conf liegen. Als Anmerkung sei gesagt, das bei mir RedHat 7.2 mit dem Kernel 2.4.17 und der Soundblaster Live!, und das problemlos, läuft. Ich habe die Treiber von http://opensource.creative.com/ bei mir am rennen. Dort bekommst Du weitere Informationen zur Installation der Soundkarte. In meiner modules.conf sind folgende Einträge zur SB Live! vorhanden. ## Soundblaster Live alias sound-service-0-0 emu10k1 pre-install emu10k1 alias sound-slot-0 emu10k1 post-install sound-slot-0 /usr/local/etc/emu-script restore pre-remove sound-slot-0 /usr/local/etc/emu-script save Gruß Michael -- Homepage temporarily out of order Registered Linux User #228306 Phone/Fax +49 7000 MACBYTE http://counter.li.org GNU PGP-Key ID 22C51B8D0140F88B ++ Webdesign ++ PHP Development ++

Dieter Kluenter

6 Feb 6 Feb

08:24

Hallo, Axel Heinrici writes:

...

Hi [...] Aber eines will natürlich trotzdem nicht mehr so richtig. Ich benutze einen soundblaster live. Beim booten erscheint in der Konsole die meldung emu10k1modprobe: can't locate module snd-card-emu10k1 . In /lib/modules/2.4.17/kernel/drivers/sound/emu10k1 gibt es ein emu10k1.o genauso wie in dem entsprechenden Verzeichnis beim alten2.4.10er Kernel. Auch ein modprobe emu10k1 gibt keine Fehlermeldung raus und der Sound funktioniert dann auch wieder. Was ist da los? Ich kenne mich leider mit den Lademechanismen für Module nicht besonders aus.

Ist der Link von /usr/src/<kernelversion> nach /usr/src/linux gestzt ? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour

Axel Heinrici

18:05

Hi On Wednesday, 6. February 2002 09:24, Dieter Kluenter wrote:

...

Ist der Link von /usr/src/<kernelversion> nach /usr/src/linux gestzt ?

Nä-- anders. Ich habe das ganze ....2.4.17.gz in mein homeverzeichnis runtergeladen und da ausgepackt. Dann hab ich das configfile aus /usr/src/linux/ (ist auf /usr/src/...2.4.10 gelinkt) in mein homeverzeichnis kopiert und dann da compiliert. Hab mich dann nur für make modules_install und cp ... /boot/bzIma.... einmal zu root gemacht. Das komische ist halt, die .config zum compilieren ist in den entsprechenden Punkten die gleiche (hab nur Bugfixes für P1 Chipsätze, Amateurfunk u. ä. rausgeschmissen) und dieses Module gibt es unter /lib/modules/2.4.17..... und /lib/modules/2.4.10.... an den gleichen Stellen. Mit dem 2.4.10er geht alles und mit dem 2.4.17er geht nur dieses eine Modul nicht. Wenn ich irgendwas beim compilieren falsch gemacht hätte, dann müsste man das doch auch an anderer Stelle merken, oder? Sonst läuft ja alles. Ok das mit dem Reiser-FS ist wahrscheinlich irgendein Problem mit der initrd, aber das kann es ja nun eigentlich auch nicht sein. Gruß Axel

Dieter Kluenter

7 Feb 7 Feb

07:07

Hallo, Axel Heinrici writes:

...

Hi

On Wednesday, 6. February 2002 09:24, Dieter Kluenter wrote:

...
Ist der Link von /usr/src/<kernelversion> nach /usr/src/linux gestzt ?

Nä-- anders. Ich habe das ganze ....2.4.17.gz in mein homeverzeichnis runtergeladen und da ausgepackt. Dann hab ich das configfile aus /usr/src/linux/ (ist auf /usr/src/...2.4.10 gelinkt) in mein homeverzeichnis kopiert und dann da compiliert. Hab mich dann nur für make modules_install und cp ... /boot/bzIma.... einmal zu root gemacht. [...] Das wird Probleme geben. Etliche Anwendungen suchen nach /usr/src/linux/include/, Wenn dann nicht der Link auf die Kernelversion mit den entsprechenden Include-Dateien gegeben ist ... Du kannst dir sicher vorstellen was dann geschieht.

-Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour

Waldemar Brodkorb

8 Feb 8 Feb

23:59

Hallo Dieter,

...

From the keyboard of Dieter,

...

Hallo,

Axel Heinrici writes:

...
Hi

On Wednesday, 6. February 2002 09:24, Dieter Kluenter wrote:

...
Ist der Link von /usr/src/<kernelversion> nach /usr/src/linux gestzt ?

Nä-- anders. Ich habe das ganze ....2.4.17.gz in mein homeverzeichnis runtergeladen und da ausgepackt. Dann hab ich das configfile aus /usr/src/linux/ (ist auf /usr/src/...2.4.10 gelinkt) in mein homeverzeichnis kopiert und dann da compiliert. Hab mich dann nur für make modules_install und cp ... /boot/bzIma.... einmal zu root gemacht. [...] Das wird Probleme geben. Etliche Anwendungen suchen nach /usr/src/linux/include/, Wenn dann nicht der Link auf die Kernelversion mit den entsprechenden Include-Dateien gegeben ist ... Du kannst dir sicher vorstellen was dann geschieht.

Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine. Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC. Hmm, was nun? Das Posting finde ich auf die schnelle nicht und in der Kernel FAQ finde ich es nicht, entweder du glaubst mir oder suchts selber *g* cya Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'

David Haller

9 Feb 9 Feb

11:42

Hallo Waldemar, On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:

...

...
From the keyboard of Dieter, [...] Das wird Probleme geben. Etliche Anwendungen suchen nach /usr/src/linux/include/, Wenn dann nicht der Link auf die Kernelversion mit den entsprechenden Include-Dateien gegeben ist ... Du kannst dir sicher vorstellen was dann geschieht.

Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine.

Da nicht. Aber sehr wohl in /usr/include/linux und /usr/include/asm. Und bei mir ist, seit 2.2.10 (aber ich hab's seit 2.0.35 so gehalten) ist (rechte/datum gekuerzt) # ls -alF /usr/include/linux /usr/include/asm /usr/src/linux /usr/include/asm -> ../src/linux/include/asm/ /usr/include/linux -> ../src/linux/include/linux/ /usr/src/linux -> linux-2.4.16/ (bzw. /usr/src/linux jew. ein link auf den dann "hauptsaechlich" verwendeten kernel... # ls -alF /boot/bzImage* /boot/vm* /boot/*/bzImage* /boot/*/vm* \ 2>/dev/null | wc -l 29

...

Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC.

Mag sein. Aber ich wuerde Linus da widersprechen. Warum? Szenario: Schritt 1: libc-foo wird gegen kernel-2.2.x kompiliert, und verwendet also das kernel-api-2.2.x. Soweit, so gut, keine Diskussion. Ob die Header dabei die vom Kernel sind, oder bei der libc "dabeiliegen" ist irrelevant. Schritt 2: Updates... a) Update des Kernels, z.B. auf 2.4.x. libc-foo verwendet aber weiter kernel-api-2.2.x. -> Was wenn "syscall x" verschwindet? Da helfen die ach so tollen header von kernel-api-2.2.x die bei der libc dabei waren auch nicht weiter... Abhilfe: Vielleicht gibt's in den kernel-2.4.x headern ein kompatibilitaets-api Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} Das (veraltete) kernel-api der libc zu verwenden, wenn der kernel das api nicht mehr unterstuetzt ist IMO eine "Bad Idea"[tm]. b) Update der libc auf Version bar Verwendet das api von kernel-<auchegal> Folgerung: wenn libc-bar auf dem api von kernel-2.4.x beruht, macht's "PENG" wenn man noch kernel-2.2 verwendet und ein in 2.2 nicht vorhandenere syscall aufgerufen wird. Abhilfe: Kernelupdate/libc downdate. Nichts was man gerne mal so eben machen wollte. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} damit solche Probleme (nicht vorhandene syscalls) wenigstens beim kompilieren schon erkannt werden, und nicht erst zur laufzeit. Das (zu neue) kernel-api der libc zu verwenden, wenn der kernel das api nicht unterstuetzt ist IMO eine "Bad Idea"[tm]. c) beides updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} da nun auch die libc das passende api verwendet d) nichts updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} siehe c). Fazit: Linus liegt IMO falsch. Ich verwende hier eine glibc-2.1.3 (gegen 2.2.10 kompiliert!) und Kernel 2.4.16 und kann mir beim besten Willen nicht vorstellen, dass ein verwenden des 2.2.10er Kernel-apis alles gut gehen wuerde. Andersrum hat Linus (und Alan und ...) gute Arbeit geleistet, und das Kernel-api (in Grenzen) abwaertskompatibel gestaltet bzw. von vorherein moegl. Erweiterungen eingeplant. Dafuer zolle ich den beteiligten auch grossen Respekt. Ich habe hier definitiv Apps laufen, die gegen die libc-2.1.3/kernel-2.2.10 + kernel-2.2.10 kompiliert wurden, gegen libc-2.1.3/kernel-2.2.10 + kernel-2.2.14 kompiliert wurden, gegen libc-2.1.3/kernel-2.2.10 + kernel-2.4.0-test1 kompiliert wurden, gegen libc-2.1.3/kernel-2.2.10 + kernel-2.4.0-test4 kompiliert wurden, gegen libc-2.1.3/kernel-2.2.10 + kernel-2.4.16 kompiliert wurden... Keine Probleme! /usr/src/linux war dabei jew. _immer_ ein link auf die jew. aktuelle Kernelversion. Ja, (u.a.) _dafuer_ zolle ich Linus Respekt. Auch "testhalber" gegen eine "glibc-2.2.x/kernel-2.2.x" bzw "glibc-2.2.x/kernel-2.4.0" kompilierte SW lief genauso gut/schlecht. IMO sollte die die libc also gegen die jew. auf dem System vorhandene kernelversion kompiliert werden. Alles andere ist (s. a-d) IMO Schwachfug. Und /usr/src/linux ein link auf die aktuell verwendete Kernelversion. Denn "diese API" wird ja zur Laufzeit dann auch konkret verwendet, s.o.... Da hilft einem ein $Uralter_Header_gegen_den_die_libc_kompiliert_ wurde genau garnicht weiter. Glaubst du, dass ne $libc < 2.1.x, die gegen kernel < 2.0.y kompiliert wurde, dass deren Header noch mit 2.5.x kompatibel sind? Eben. Wenn man ne Chance hat, dann mit den aktuellen Headern! Denn der tollste header taucht nix, wenn's keine SW gibt die's auch implementiert! Du kannst 1000endmal ein "foo()" im (alten) (kernel) heeader haben und evtl. dagegen sogar kompilieren, wenn der (aktuelle!!!) Kernel foo() aber nicht mehr hat, stehst du doch ein wenig "dumm da"...

...

Hmm, was nun? Das Posting finde ich auf die schnelle nicht und in der Kernel FAQ finde ich es nicht, entweder du glaubst mir oder suchts selber *g*

Tja. ;) Ich glaube, ich hab das schon irgendwo mal gelesen... Und, s.o. ich widerspreche Linus' Meinung. So sehr ich Linus, Alan et.al respektiere, aber vom verlinken vom /usr/src/linux auf die jew. aktuell verwendete Kernelversion (und somit auch /usr/include/{asm,linux}) wird mich das nicht abhalten... -dnh, wie erwaehnt, seit 2.0.35 dieses Schema konsequent verwendend ;) -- 9: GUI Ein Hintergrundbild und 12 Xterms (Kristian Köhntopp)

Axel Heinrici

10 Feb 10 Feb

15:47

Hi Ich hab' es jetzt. Es lag nicht am Pfad. Ich habe den Tip von Manfred Tremmel gehalten und neue ALSA-Software kompiliert und installiert. ---Problem gelöst! Gruß Axel

Christoph Maurer

12 Feb 12 Feb

07:00

Am Sam, 09 Feb 2002 schrieb David Haller:

...

Hallo Waldemar,

On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:

...
...
...
From the keyboard of Dieter, [...] Das wird Probleme geben. Etliche Anwendungen suchen nach /usr/src/linux/include/, Wenn dann nicht der Link auf die Kernelversion mit den entsprechenden Include-Dateien gegeben ist ... Du kannst dir sicher vorstellen was dann geschieht.

Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine.

Da nicht. Aber sehr wohl in /usr/include/linux und /usr/include/asm. Und bei mir ist, seit 2.2.10 (aber ich hab's seit 2.0.35 so gehalten) ist (rechte/datum gekuerzt)

# ls -alF /usr/include/linux /usr/include/asm /usr/src/linux /usr/include/asm -> ../src/linux/include/asm/ /usr/include/linux -> ../src/linux/include/linux/ /usr/src/linux -> linux-2.4.16/

War ja auch lange bei den Distributoren so gehalten und seit 7.2 ist SuSE wieder davon abgegangen.

...

...
Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC.

Mag sein. Aber ich wuerde Linus da widersprechen. Warum?

Vielleicht solltest Du das mal auf der lkml mit ihm besprechen, würde mich interessieren, was dabei rauskommt.

...

Szenario:

Schritt 1: libc-foo wird gegen kernel-2.2.x kompiliert, und verwendet also das kernel-api-2.2.x. Soweit, so gut, keine Diskussion. Ob die Header dabei die vom Kernel sind, oder bei der libc "dabeiliegen" ist irrelevant.

ACK.

...

Schritt 2: Updates...

a) Update des Kernels, z.B. auf 2.4.x. libc-foo verwendet aber weiter kernel-api-2.2.x. -> Was wenn "syscall x" verschwindet? Da helfen die ach so tollen header von kernel-api-2.2.x die bei der libc dabei waren auch nicht weiter... Abhilfe: Vielleicht gibt's in den kernel-2.4.x headern ein kompatibilitaets-api Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} Das (veraltete) kernel-api der libc zu verwenden, wenn der kernel das api nicht mehr unterstuetzt ist IMO eine "Bad Idea"[tm].

Ich gebe Dir recht, daß es ein Problem sein könnte, wenn der Kernel in den original Headeren deklarierte Aufrufe nicht mehr unterstützt, gehe aber mal davon aus (ohne es belegen zu können), daß der weitgehend abwärtskompatibel gehalten wurde. Aber das Problem ist doch hier die Aufwärtskompatibilität. Wenn Du die Header des aktuellen Kernels als Includes verwendest, sind dort u.U. Funktionen deklariert, die in der glibc nicht unterstützt sind, das bedeutet es wird einen Linker-Fehler geben. Wenn Du jetzt nicht weißt, woran das liegen könnte, wirst Du als Programmierer doch bekloppt. IMHO gibt es keine andere Alternative, als beim arbeiten mit Bibliotheken und Include-Dateien, die exakt zueinander passenden Versionen zu verwenden.

...

b) Update der libc auf Version bar Verwendet das api von kernel-<auchegal> Folgerung: wenn libc-bar auf dem api von kernel-2.4.x beruht, macht's "PENG" wenn man noch kernel-2.2 verwendet und ein in 2.2 nicht vorhandenere syscall aufgerufen wird. Abhilfe: Kernelupdate/libc downdate. Nichts was man gerne mal so eben machen wollte. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} damit solche Probleme (nicht vorhandene syscalls) wenigstens beim kompilieren schon erkannt werden, und nicht erst zur laufzeit. Das (zu neue) kernel-api der libc zu verwenden, wenn der kernel das api nicht unterstuetzt ist IMO eine "Bad Idea"[tm].

Gebe Dir recht, das es wohl keine gute Idee ist, eine libc zu verwenden, die gegen einen neueren Kernel, als der von einem selbst eingesetzte, kompiliert wurde, zu verwenden.

...

c) beides updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} da nun auch die libc das passende api verwendet

Geht aber nur, wenn Du nur eine Kernel-Version parallel verwendest. Ist bei mir nicht unbedingt so.

...

d) nichts updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} siehe c).

Fazit: Linus liegt IMO falsch.

IMHO nicht.

...

Ich verwende hier eine glibc-2.1.3 (gegen 2.2.10 kompiliert!) und Kernel 2.4.16 und kann mir beim besten Willen nicht vorstellen, dass ein verwenden des 2.2.10er Kernel-apis alles gut gehen wuerde.

Verwende eine lib 2.1.? gegen Kernel 2.2.16 kompiliert und seitdem einige 2.2er und 2.4er Kernel (mittlerweile 2.4.14) und /usr/src/linux zeigt immer auf die Includes des 2.2.16er Kernels -> nie Probleme. FYI: Linus Meinung dazu findest Du hier: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html Aus dem Posting geht IMHO auch hervor, daß der Kernel abwärtskompatibel gehalten wird. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

David Haller

13 Feb 13 Feb

03:17

Hallo, On Tue, 12 Feb 2002, Christoph Maurer wrote:

...

Am Sam, 09 Feb 2002 schrieb David Haller:

...
On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:

...
Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine.

Da nicht. Aber sehr wohl in /usr/include/linux und /usr/include/asm. Und bei mir ist, seit 2.2.10 (aber ich hab's seit 2.0.35 so gehalten) ist (rechte/datum gekuerzt)

# ls -alF /usr/include/linux /usr/include/asm /usr/src/linux /usr/include/asm -> ../src/linux/include/asm/ /usr/include/linux -> ../src/linux/include/linux/ /usr/src/linux -> linux-2.4.16/

War ja auch lange bei den Distributoren so gehalten und seit 7.2 ist SuSE wieder davon abgegangen.

Aha :)

...

...
...
Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC.

Mag sein. Aber ich wuerde Linus da widersprechen. Warum?

Vielleicht solltest Du das mal auf der lkml mit ihm besprechen, würde mich interessieren, was dabei rauskommt.

Mmmm... Dazu muesste ich Linus' Argumentation erstmal genau lesen... (danke fuer die URL). Was ich schrieb, war schlicht aus meinem Verstaendnis des Zusammenspiels von libs/headern/kernel heraus...

...

...
Szenario:

Schritt 1: libc-foo wird gegen kernel-2.2.x kompiliert, und verwendet also das kernel-api-2.2.x. Soweit, so gut, keine Diskussion. Ob die Header dabei die vom Kernel sind, oder bei der libc "dabeiliegen" ist irrelevant.

ACK.

*g*

...

...
Schritt 2: Updates...

a) Update des Kernels, z.B. auf 2.4.x. libc-foo verwendet aber weiter kernel-api-2.2.x. [..] Ich gebe Dir recht, daß es ein Problem sein könnte, wenn der Kernel in den original Headeren deklarierte Aufrufe nicht mehr

s/original/libc/

...

unterstützt, gehe aber mal davon aus (ohne es belegen zu können), daß [das kernel-api] weitgehend abwärtskompatibel gehalten wurde.

Ja wird es. Und das ist gut. In gewissen Grenzen (siehe M$, siehe meine Erfahrungen (libc gegen 2.2.10, kernel 2.4.x). Aber das ist nicht "garantiert" fuer 2.6 oder ... Und wenn, dann will ich Probleme beim kompilieren "mitbekommen"!

...

Aber das Problem ist doch hier die Aufwärtskompatibilität. Wenn Du die Header des aktuellen Kernels als Includes verwendest, sind dort u.U. Funktionen deklariert, die in der glibc nicht unterstützt sind, das bedeutet es wird einen Linker-Fehler geben.

Nein, eben nicht(!). Nicht verwendete Funktionen sind irrelevant. z.B. ist der Grossteil der glibc-2.2 noch "identisch" zur glibc-2.0. (sieh dir mal ein 'nm' eines gegen die glibc-2.2 gelinkten binaries an). Was interessiert's wenn es nicht nur 'int foo', sondern zusaetzlich noch ein 'int bar' gibt, solange es 'int foo' noch gibt? Probleme gibt's, wenn 'int bar' gewollt wird, aber es nur 'int foo' (und nicht beide) gibt...

...

Wenn Du jetzt nicht weißt, woran das liegen könnte, wirst Du als Programmierer doch bekloppt.

s.o. irrelevant.

...

IMHO gibt es keine andere Alternative, als beim arbeiten mit Bibliotheken und Include-Dateien, die exakt zueinander passenden Versionen zu verwenden.

Noe. Ich habe schon mehrfach Programme gegen (angeblich) zu alte libs erfolgreich gelinkt, weil die Programme nicht wirklich die neuen Funktionen verwendeten (u.a. gegen libc, libgtk, libgnome u.a.). Wie gesagt: was nicht verwendet wird ist irrelevant. Probier's mal aus: Verwende eine glibc-2.0 funktion mit glibc-2.2. Verwende ne glibc-2.2 Funktion (die's in 2.0 noch nicht gab) mit 2.0... Und was "ueberfluessigerweise" noch in Headern deklariert wird, ist dabei auch egal...

...

...
b) Update der libc auf Version bar Verwendet das api von kernel-<auchegal> Folgerung: wenn libc-bar auf dem api von kernel-2.4.x beruht, macht's "PENG" wenn man noch kernel-2.2 verwendet und ein in 2.2 nicht vorhandenere syscall aufgerufen wird. [..] Gebe Dir recht, das es wohl keine gute Idee ist, eine libc zu verwenden, die gegen einen neueren Kernel, als der von einem selbst eingesetzte, kompiliert wurde, zu verwenden.

"Keine gute Idee" ist untertrieben... Entweder es klappts (siehe oben), oder es klappt eben (komplett!) nicht...

...

...
c) beides updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} da nun auch die libc das passende api verwendet

Geht aber nur, wenn Du nur eine Kernel-Version parallel verwendest. Ist bei mir nicht unbedingt so.

# ls /boot/vm* /boot/bzI* /boot/2.2.1*/{bzI,vm}* | wc -l 35 Wie meinen? /me und nicht mehrere Kernel??? Du kennst mein "mini-Howto" zu dem Thema? Warum hab ich das wohl geschrieben? *eg*

...

...
d) nichts updaten. Folgerung: /usr/src/linux -> /usr/src/linux-${current_version} siehe c).

Fazit: Linus liegt IMO falsch.

IMHO nicht.

<repeat ad infinitum> *eg*

...

...
Ich verwende hier eine glibc-2.1.3 (gegen 2.2.10 kompiliert!) und Kernel 2.4.16 und kann mir beim besten Willen nicht vorstellen, dass ein verwenden des 2.2.10er Kernel-apis alles gut gehen wuerde.

Verwende eine lib 2.1.? gegen Kernel 2.2.16 kompiliert und seitdem einige 2.2er und 2.4er Kernel (mittlerweile 2.4.14) und /usr/src/linux zeigt immer auf die Includes des 2.2.16er Kernels -> nie Probleme.

Eben. Ich ja auch. Das Kernel-Api _ist_ eben (zum Glueck) abwaerts- kompatibel (zumindest zwischen 2.2.x und 2.4.x, gegen 2.0.x gibt's AFAIR ein paar Inkompatibilitaeten... Mehr als das der glibc, IIRC.

...

FYI: Linus Meinung dazu findest Du hier: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html

Merci.

...

Aus dem Posting geht IMHO auch hervor, daß der Kernel abwärtskompatibel gehalten wird.

Genau. Eben. Mehr als die glibc. Ergo: /usr/src/linux -> linux-${current_version}. Denn so bekommt man ggfs. auftretenden Inkompatibilitaeten mit! Achso: Ich sollte wohl noch betonen, (worueber es AFAIR bei diesem Streit auch geht), dass IMO _KEINE_ libc header sind, sondern Kernel-header, siehe meine bisherige Argumentation. Kernel-header sind und bleiben Kernel-header, egal was die libc dazu meint. Wenn dann eine Inkompatibilitaet auftritt will ich das wissen, und nicht durch (zu alte) libc-pseudo-kernel-header verdeckt wissen. Nach letzterm Schema koenntest du ne gegen Kernel 1.0 kompilierte libc mit kernel-1.0-headern verwenden, aber dann nen 2.5.x Kernel verwenden, ohne dass das beim kompilieren auffallen wuerde -- aber wetten, dass das dann zur Laufzeit schiefginge? Andersrum: libc-aktuell + Kernel-header 1.0 wuerde beim kompilieren auffallen, denn libc-aktuell wurde kernel-funktionen verwenden wollen, die es weder im Kernel-1.0 gibt, noch in dessen headern (eben, deshalb, weil's die im kernel nicht gibt)... Die Frage ist also IMO: Wo soll's "krachen", beim kompilieren oder zur Laufzeit? Und nein, ich glaube nicht, dass du letzteres vorziehen wuerdest!!! Aber wie gesagt, ich muss mir da die Diskussion (besonders Linus' Argumentation nochmal genauer "reinziehen" :) -dnh -- 111: Grundgesetz der Signalverarbeitung mit Modem Wenn man ein schnelleres Modem installiert, gibt es immer auch jemanden, der danach langsamere Verbindungen bekommt. (Erik Heinz)

Christoph Maurer

18:19

Am Mit, 13 Feb 2002 schrieb David Haller:

...

On Tue, 12 Feb 2002, Christoph Maurer wrote:

...
Am Sam, 09 Feb 2002 schrieb David Haller:

...
On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:

...

...
...
...
[/usr/src/linux link auf verwendete Kernelquellen oder auf includes, gegen die glibc kompiliert wurde]

...

...
...
Schritt 2: Updates...

a) Update des Kernels, z.B. auf 2.4.x. libc-foo verwendet aber weiter kernel-api-2.2.x. [..] Ich gebe Dir recht, daß es ein Problem sein könnte, wenn der Kernel in den original Headeren deklarierte Aufrufe nicht mehr

s/original/libc/

Ja, natürlich.

...

...
unterstützt, gehe aber mal davon aus (ohne es belegen zu können), daß [das kernel-api] weitgehend abwärtskompatibel gehalten wurde.

Ja wird es. Und das ist gut. In gewissen Grenzen (siehe M$, siehe meine Erfahrungen (libc gegen 2.2.10, kernel 2.4.x).

Aber das ist nicht "garantiert" fuer 2.6 oder ... Und wenn, dann will ich Probleme beim kompilieren "mitbekommen"!

Sicher, da gibt es bestimmt Grenzen, aber solange die Kompatibilität im Rahmen eines Versionssprungs (2.2->2.4 bzw. 2.4->2.6) gewahrt bleibt, sollten die meisten Benutzer damit leben können. Oder willst Du Deine 6.2 auch in ca. 2 Jahren, wenn man 2.6 benutzen kann, noch verwenden :)

...

...
Aber das Problem ist doch hier die Aufwärtskompatibilität. Wenn Du die Header des aktuellen Kernels als Includes verwendest, sind dort u.U. Funktionen deklariert, die in der glibc nicht unterstützt sind, das bedeutet es wird einen Linker-Fehler geben.

Nein, eben nicht(!). Nicht verwendete Funktionen sind irrelevant. z.B. ist der Grossteil der glibc-2.2 noch "identisch" zur glibc-2.0. (sieh dir mal ein 'nm' eines gegen die glibc-2.2 gelinkten binaries an).

Ja, aber was ist, wenn Du als Programmierer einen Aufruf, korrekt gemäß Header-Files, verwendest, der aber nicht gelinkt werden kann, da in verwendeter glibc noch nicht implementiert. Oder noch schlimmer, und darauf bezieht sich Linus in u.g. URL, wenn eine neuere Version eine struct X reimplementiert.

...

...
IMHO gibt es keine andere Alternative, als beim arbeiten mit Bibliotheken und Include-Dateien, die exakt zueinander passenden Versionen zu verwenden.

Noe. Ich habe schon mehrfach Programme gegen (angeblich) zu alte libs erfolgreich gelinkt, weil die Programme nicht wirklich die neuen Funktionen verwendeten (u.a. gegen libc, libgtk, libgnome u.a.).

Ist ja logisch, IIRC meine Vorlesung in Internprogrammierung, bietet die Bibliothek so eine Art Inhaltsverzeichnis am Anfang, wo Du über den Namen die Einsprungadresse findest. Solange alle gewünschten Namen (i.e. im Wesentlichen unter C alle Funktionsnamen, bei C++ wirds komplizierter, ist aber hier nicht das Thema) aufgelöst werden können, klappt das Linken.

...

...
...
[...] <repeat ad infinitum> *eg*

Na, ich hoffe nicht, bisher ist die Diskussion auf jeden Fall noch fruchtbar.

...

...
FYI: Linus Meinung dazu findest Du hier: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html

Merci.

...
Aus dem Posting geht IMHO auch hervor, daß der Kernel abwärtskompatibel gehalten wird.

Genau. Eben. Mehr als die glibc. Ergo: /usr/src/linux -> linux-${current_version}.

Denn so bekommt man ggfs. auftretenden Inkompatibilitaeten mit!

Dafür bekommst Du u.U. Compilerfehler, wo es überhaupt kein Problem gibt.

...

Achso: Ich sollte wohl noch betonen, (worueber es AFAIR bei diesem Streit auch geht), dass IMO _KEINE_ libc header sind, sondern Kernel-header, siehe meine bisherige Argumentation.

Ja, die einmal für die Kompilierung der libc herangezogen werden und dann deshalb libc-Header sind.

...

Kernel-header sind und bleiben Kernel-header, egal was die libc dazu meint. Wenn dann eine Inkompatibilitaet auftritt will ich das wissen, und nicht durch (zu alte) libc-pseudo-kernel-header verdeckt wissen. Nach letzterm Schema koenntest du ne gegen Kernel 1.0 kompilierte libc mit kernel-1.0-headern verwenden, aber dann nen 2.5.x Kernel verwenden, ohne dass das beim kompilieren auffallen wuerde -- aber wetten, dass das dann zur Laufzeit schiefginge?

s.o. alles hat Grenzen und Dein Ansatz schließt sowas sicher aus. Aber wer will das oben skizzierte? Du hast mich davon überzeugt, daß es Szenarien gibt, in denen die von mir propagierte Vorgehensweise Fehler zur Laufzeit gibt, die Du ausschließen kannst, nämlich immer dann, wenn die Abwärtskompatibilität des Kernels aufgegeben wird. Vielleicht sollte man im Kernel angeben, bis zu welcher Version er abwärtskompatibel ist. Genauso kann es aber IMHO bei Deiner Vorgehensweise zu Laufzeitfehlern kommen, da Deine (so verstehe ich zumindest Linus Argumentation) alte libc bei Reimplementierungen einer Datenstruktur den alten (in der neuen Kernelversion aus Gründen der Abwärtskompatibilität weiterhin enthaltenen) syscall aufruft (der natürlich auch noch die alte Datenstruktur erwartet), aber gemäß der Informationen zur Compilezeit schon die neue Datenstruktur verwendet. Das wird beim Kompiliern nicht auffallen (da allein Header ausschlaggebend) beim Linken aber auch nicht, da die Strukturen den gleichen Namen haben und somit der Linken keinen Grund zum Meckern sieht. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

David Haller

14 Feb 14 Feb

00:18

Hallo, On Wed, 13 Feb 2002, Christoph Maurer wrote:

...

Am Mit, 13 Feb 2002 schrieb David Haller:

...
On Tue, 12 Feb 2002, Christoph Maurer wrote:

...
Am Sam, 09 Feb 2002 schrieb David Haller:

...
On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:

...
...
...
...
[/usr/src/linux link auf verwendete Kernelquellen oder auf includes, gegen die glibc kompiliert wurde] unterstützt, gehe aber mal davon aus (ohne es belegen zu können), daß [das kernel-api] weitgehend abwärtskompatibel gehalten wurde.

Ja wird es. Und das ist gut. In gewissen Grenzen (siehe M$, siehe meine Erfahrungen (libc gegen 2.2.10, kernel 2.4.x).

Aber das ist nicht "garantiert" fuer 2.6 oder ... Und wenn, dann will ich Probleme beim kompilieren "mitbekommen"!

Sicher, da gibt es bestimmt Grenzen, aber solange die Kompatibilität im Rahmen eines Versionssprungs (2.2->2.4 bzw. 2.4->2.6) gewahrt bleibt, sollten die meisten Benutzer damit leben können. Oder willst Du Deine 6.2 auch in ca. 2 Jahren, wenn man 2.6 benutzen kann, noch verwenden :)

Warum nicht? Meine 6.2 ist sowieso schon, mompl... $ rpm -qa --queryformat "%{installtime} %{name}\n" | sort -n | head -1 934823966 bc $ epochtodate 934823966 Mon 16.08.1999 19:19:04 CEST ... ca. 2 1/2 Jahre alt, da macht's nimmer viel, wenn die noch aelter wird :) Is natuerlich vieles aktualisiert bzw. selbstkompiliert... Wenn ich (demnaechst evtl.) mal wieder neu installiere, dann vermutlich eh keine Susi, sondern LFS oder (vielleicht) ne Debilian... *eg*

...

...
...
Aber das Problem ist doch hier die Aufwärtskompatibilität. Wenn Du die Header des aktuellen Kernels als Includes verwendest, sind dort u.U. Funktionen deklariert, die in der glibc nicht unterstützt sind, das bedeutet es wird einen Linker-Fehler geben.

Nein, eben nicht(!). Nicht verwendete Funktionen sind irrelevant. z.B. ist der Grossteil der glibc-2.2 noch "identisch" zur glibc-2.0. (sieh dir mal ein 'nm' eines gegen die glibc-2.2 gelinkten binaries an).

Ja, aber was ist, wenn Du als Programmierer einen Aufruf, korrekt gemäß Header-Files, verwendest, der aber nicht gelinkt werden kann, da in verwendeter glibc noch nicht implementiert.

Oder noch schlimmer, und darauf bezieht sich Linus in u.g. URL, wenn eine neuere Version eine struct X reimplementiert.

Jep. Aber: siehe z.B. http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0616.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0625.html Das ganze sieht mir eh ziemlich wuest aus... IMO entsteht der "nicht aufloesbare" Konflikt dann, wenn structs (u.ae.) im Kernel geaendert werden (nicht nur "erweitert"[1]), aber dabei nicht umbenamst werden.

...

...
...
IMHO gibt es keine andere Alternative, als beim arbeiten mit Bibliotheken und Include-Dateien, die exakt zueinander passenden Versionen zu verwenden.

Noe. Ich habe schon mehrfach Programme gegen (angeblich) zu alte libs erfolgreich gelinkt, weil die Programme nicht wirklich die neuen Funktionen verwendeten (u.a. gegen libc, libgtk, libgnome u.a.).

Ist ja logisch, IIRC meine Vorlesung in Internprogrammierung, bietet die Bibliothek so eine Art Inhaltsverzeichnis am Anfang, wo Du über den Namen die Einsprungadresse findest. Solange alle gewünschten Namen (i.e. im Wesentlichen unter C alle Funktionsnamen, bei C++ wirds komplizierter, ist aber hier nicht das Thema) aufgelöst werden können, klappt das Linken.

ACK. Ich sehe mein "zu kurz" Denken, ISC. ;) Aber s. [1] und die o.g. Urls, auch Linus' kategorisches "keine symlinks" ist "zu kurz" gedacht, und (lt. der Mail, zu der du die URL gemailt hast), verwendet er eine aehnlich "inkonsistente", aber "entgegengesetzte" Konstellation, die (genau wie meine wohl) klappt, weil der Kernel eben abwaertskompatibel ist :) (IIRC ist meine glibc auch gegen 2.2.10 gelinkt, und ich verwende Kernel 2.4.x *lol*)

...

...
...
...
[...] <repeat ad infinitum> *eg*

Na, ich hoffe nicht, bisher ist die Diskussion auf jeden Fall noch fruchtbar.

Ack!

...

...
...
FYI: Linus Meinung dazu findest Du hier: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html

Merci.

...
Aus dem Posting geht IMHO auch hervor, daß der Kernel abwärtskompatibel gehalten wird.

Genau. Eben. Mehr als die glibc. Ergo: /usr/src/linux -> linux-${current_version}.

Denn so bekommt man ggfs. auftretenden Inkompatibilitaeten mit!

Dafür bekommst Du u.U. Compilerfehler, wo es überhaupt kein Problem gibt.

Dazu kann ich nur sagen: na immerhin das! Da weiss ich wenigstens, dass etwas schiefgeht. Ein "kommentarloses" durchkompilieren hilft mir bei so einem Konflikt (in beiden Szenarios) nicht, wenn ich dann "vertrauens- voll" den scheinbar fehlerlos kompilierten Kernel testen will... Generell: Compiletime Fehler (egal welcher Art!) sind mir immer lieber als Runtime-Fehler. Achso, zu dem was Linus meinte: ich denke, ich weiss zumindest teil- weise, was ich tue, wenn ich den symlink setze... :)

...

...
Achso: Ich sollte wohl noch betonen, (worueber es AFAIR bei diesem Streit auch geht), dass IMO _KEINE_ libc header sind, sondern Kernel-header, siehe meine bisherige Argumentation.

Ja, die einmal für die Kompilierung der libc herangezogen werden und dann deshalb libc-Header sind.

Nein. Es sind die Kernel-header, gegen die die libc kompiliert wurde. Hey, ein libc Entwickler koennte sonst ja, in einem "libc-pseudo-kernel- header" sonstwas deklarieren, z.B. 'struct X { char c; }' statt 'struct X { int foo; }'... Wenn das nicht zum Kernel passt... Ich meine, die libc kann ueber den Kernel behaupten was sie will, entscheidend ist, was in _meinem_ Kernel drin ist. Wenn's Konflikte gibt, sind das libc Konflikte, denn die glibc ist "userland", genau wie jede andere lib, die auf syscalls, ioctls oder sonstige Kernelfunktionen/-features zugreift. Dass die libc "eigene" kernel-header mitbringen soll(te) ist IMO Schwach- fug. Die koennte ja, wie gesagt, Kernel 0.0.99 header oder sonstwas mit- liefern... (klar, siehe Linus' oder meine Konstellation, es geht "lange" gut, aber nur eben bis...). Es macht natuerlich weder Sinn nen aktuellen Kernel mit ner uralt libc, oder ne aktuelle libc mit nem uralt Kernel zu verwenden...

...

...
Kernel-header sind und bleiben Kernel-header, egal was die libc dazu meint. Wenn dann eine Inkompatibilitaet auftritt will ich das wissen, und nicht durch (zu alte) libc-pseudo-kernel-header verdeckt wissen. Nach letzterm Schema koenntest du ne gegen Kernel 1.0 kompilierte libc mit kernel-1.0-headern verwenden, aber dann nen 2.5.x Kernel verwenden, ohne dass das beim kompilieren auffallen wuerde -- aber wetten, dass das dann zur Laufzeit schiefginge?

s.o. alles hat Grenzen und Dein Ansatz schließt sowas sicher aus.

Eben.

...

Aber wer will das oben skizzierte?

Ich! Wenn auch nicht unbedingt so extrem :)

...

Du hast mich davon überzeugt, daß es Szenarien gibt, in denen die von mir propagierte Vorgehensweise Fehler zur Laufzeit gibt, die Du ausschließen kannst, nämlich immer dann, wenn die Abwärtskompatibilität des Kernels aufgegeben wird. Vielleicht sollte man im Kernel angeben, bis zu welcher Version er abwärtskompatibel ist.

Genau. Siehe [1] :). IMO stimmt beides *lol*. Die Frage ist, welche Strategie man zur "Konfliktaufdeckung" moechte...

...

Genauso kann es aber IMHO bei Deiner Vorgehensweise zu Laufzeitfehlern kommen, da Deine (so verstehe ich zumindest Linus Argumentation) alte libc bei Reimplementierungen einer Datenstruktur den alten (in der neuen Kernelversion aus Gründen der Abwärtskompatibilität weiterhin enthaltenen) syscall aufruft (der natürlich auch noch die alte Datenstruktur erwartet), aber gemäß der Informationen zur Compilezeit schon die neue Datenstruktur verwendet. Das wird beim Kompiliern nicht auffallen (da allein Header ausschlaggebend) beim Linken aber auch nicht, da die Strukturen den gleichen Namen haben und somit der Linken keinen Grund zum Meckern sieht.

Ack. Und das ist dann IMO ein Fehler (s. [1]) im Kernel. Insgesamt eine ziemlich unschoene Situation, fuer die's (tippe ich mal) nur die Loesung der korrekten Versionierung der Kernelsymbole gibt, wo dann eben die glibc (oder sonst eine lib/Programm) eben eine bestimmte (Mindest-)Version eines Symbols verlangen kann, wie auch bei der glibc. -dnh [1] ein struct X { int foo; int bar; } ist doch AFAIK "rueckwaertskompatibel" zu struct X { int foo; } da foo "noch da ist", und "dass da noch mehr drin is", ist AFAIK egal. Ein struct X { int bar; } hingegen nicht. Eine Versionierung der Kernelsymbole wie in der glibc waere aber IMO eine gute Idee. Wenn da z.B. ein Programm "struct X@kernel_2_0" verlangt, und diese auch noch im Kernel 2.6 drin ist, ist alles in Butter, wenn die Struktur ohne Umbenamsung geaendert wird, waere es eben dann struct X@kernel_2_0 und der linker koennte den Konflikt erkennen (siehe die Ausgabe von nm bei einem beliebigen gegen die libc gelinkten Programm...) -- We have joy, we have fun, we have Linux on our SUN -- from a sig of Peter Lemken

Christoph Maurer

06:57

Am Don, 14 Feb 2002 schrieb David Haller:

...

Hallo,

On Wed, 13 Feb 2002, Christoph Maurer wrote:

...
Am Mit, 13 Feb 2002 schrieb David Haller:

...
On Tue, 12 Feb 2002, Christoph Maurer wrote:

...
Am Sam, 09 Feb 2002 schrieb David Haller:

...
On Sat, 09 Feb 2002, Waldemar Brodkorb wrote:

...
...
...
...
[/usr/src/linux link auf verwendete Kernelquellen oder auf includes, gegen die glibc kompiliert wurde] Aber das Problem ist doch hier die Aufwärtskompatibilität. Wenn Du die Header des aktuellen Kernels als Includes verwendest, sind dort u.U. Funktionen deklariert, die in der glibc nicht unterstützt sind, das bedeutet es wird einen Linker-Fehler geben.

Nein, eben nicht(!). Nicht verwendete Funktionen sind irrelevant. z.B. ist der Grossteil der glibc-2.2 noch "identisch" zur glibc-2.0. (sieh dir mal ein 'nm' eines gegen die glibc-2.2 gelinkten binaries an).

Ja, aber was ist, wenn Du als Programmierer einen Aufruf, korrekt gemäß Header-Files, verwendest, der aber nicht gelinkt werden kann, da in verwendeter glibc noch nicht implementiert.

Oder noch schlimmer, und darauf bezieht sich Linus in u.g. URL, wenn eine neuere Version eine struct X reimplementiert.

Jep. Aber: siehe z.B.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0616.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0625.html

Interessant.

...

Das ganze sieht mir eh ziemlich wuest aus... IMO entsteht der "nicht aufloesbare" Konflikt dann, wenn structs (u.ae.) im Kernel geaendert werden (nicht nur "erweitert"[1]), aber dabei nicht umbenamst werden.

Ja, je länger ich darüber nachdenke, desto mehr scheint mir darin das größte Problem an der ganzen Sache zu liegen.

...

...
...
...
FYI: Linus Meinung dazu findest Du hier: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html

Merci.

...
Aus dem Posting geht IMHO auch hervor, daß der Kernel abwärtskompatibel gehalten wird.

Genau. Eben. Mehr als die glibc. Ergo: /usr/src/linux -> linux-${current_version}.

Denn so bekommt man ggfs. auftretenden Inkompatibilitaeten mit! [...] [...] Es macht natuerlich weder Sinn nen aktuellen Kernel mit ner uralt libc, oder ne aktuelle libc mit nem uralt Kernel zu verwenden...

Full ACK, beides kann zu Laufzeitfehlern führen.

...

...
...
[...] [...] Insgesamt eine ziemlich unschoene Situation, fuer die's (tippe ich mal) nur die Loesung der korrekten Versionierung der Kernelsymbole gibt, wo dann eben die glibc (oder sonst eine lib/Programm) eben eine bestimmte (Mindest-)Version eines Symbols verlangen kann, wie auch bei der glibc.

Und da haben wir dann glaube ich einen Punkt erreicht, auf den wir uns alle einigen können. Nur so ist das Problem an der Wurzel zu packen. Jetzt muß man nur noch Linus überzeugen. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

Christoph Maurer

12 Feb 12 Feb

06:44

Am Sam, 09 Feb 2002 schrieb Waldemar Brodkorb:

...

Hallo Dieter,

...
From the keyboard of Dieter, Axel Heinrici writes:

...
On Wednesday, 6. February 2002 09:24, Dieter Kluenter wrote:

...
Ist der Link von /usr/src/<kernelversion> nach /usr/src/linux gestzt ?

Nä-- anders. Ich habe das ganze ....2.4.17.gz in mein homeverzeichnis runtergeladen und da ausgepackt. Dann hab ich das configfile aus /usr/src/linux/ (ist auf /usr/src/...2.4.10 gelinkt) in mein homeverzeichnis kopiert und dann da compiliert. Hab mich dann nur für make modules_install und cp ... /boot/bzIma.... einmal zu root gemacht. [...] Das wird Probleme geben. Etliche Anwendungen suchen nach /usr/src/linux/include/, Wenn dann nicht der Link auf die Kernelversion mit den entsprechenden Include-Dateien gegeben ist ... Du kannst dir sicher vorstellen was dann geschieht.

Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine. ACK. Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC. Nein, das Problem bei alten Versionen (bis einschl. 7.1 bei SuSE, wann es bei RH et al. geändert wurde bzw. ob überhaupt, weiß ich nicht), daß /usr/include/linux ein Link auf /usr/src/linux/include war. Und /usr/include/linux wird von allen Programmen zur Compilezeit benötigt, die gegen glibc linken.

Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

David Haller

13 Feb 13 Feb

03:21

Hallo, On Tue, 12 Feb 2002, Christoph Maurer wrote:

...

Am Sam, 09 Feb 2002 schrieb Waldemar Brodkorb:

...
Hallo Dieter,

...
From the keyboard of Dieter, Axel Heinrici writes:

...
On Wednesday, 6. February 2002 09:24, Dieter Kluenter wrote:

...
Ist der Link von /usr/src/<kernelversion> nach /usr/src/linux gestzt ?

Nä-- anders. Ich habe das ganze ....2.4.17.gz in mein homeverzeichnis runtergeladen und da ausgepackt. Dann hab ich das configfile aus /usr/src/linux/ (ist auf /usr/src/...2.4.10 gelinkt) in mein homeverzeichnis kopiert und dann da compiliert. Hab mich dann nur für make modules_install und cp ... /boot/bzIma.... einmal zu root gemacht. [...] Das wird Probleme geben. Etliche Anwendungen suchen nach /usr/src/linux/include/, Wenn dann nicht der Link auf die Kernelversion mit den entsprechenden Include-Dateien gegeben ist ... Du kannst dir sicher vorstellen was dann geschieht.

Welche Anwendungen suchen zur Laufzeit in /usr/src/linux/include/? keine. ACK. Welche Anwendung sucht zur Compilezeit in /usr/src/linux/include/? kaputte, laut Linus Torvalds IIRC. Nein, das Problem bei alten Versionen (bis einschl. 7.1 bei SuSE, wann es bei RH et al. geändert wurde bzw. ob überhaupt, weiß ich nicht), daß /usr/include/linux ein Link auf /usr/src/linux/include war. Und /usr/include/linux wird von allen Programmen zur Compilezeit benötigt, die gegen glibc linken.

Ja. Aber diese Header werden nicht eingebunden, um glibc- Funktionen zu deklarieren, sondern um das _vom verwendeten Kernel_ bereitgestellte API zu deklarieren. Und ergo sollte _dieses_ API auch mit dem verwendeten Kernel zusammenpassen, und da eine "Aufwaerts- kompatibilitaet" quasi unmoeglich ist, eine Abwaertskompatibilitaet aber relativ einfach... Und das Kernel-Api _ist_ (relativ weitgehend) abwaerts-, aber nicht aufwaerts kompatibel (weisst du, was in Kernel 2.8.x drin sein wird?)... Folgerung: Siehe meine anderen Mails... -dnh -- How the boss came up with this brilliant idea is so fscking far beyond my logic, that in order to see it clearly, I would have to drain 50% of the blood from my body, and ingest LSD laced with PCP and turpentine. -- Stephen Edwards

David Haller

7 Feb 7 Feb

08:07

Hallo, On Wed, 06 Feb 2002, Axel Heinrici wrote: [neuer Kernel]

...

Ok das mit dem Reiser-FS ist wahrscheinlich irgendein Problem mit der initrd, aber das kann es ja nun eigentlich auch nicht sein.

Du hast deine SW auf dem Stand, der in Documentation/Changes gefordert wird? Insbesondere die modutils? Ansonsten: du kennst <eigenwerbung>http://www.dhaller.de/linux/multikernel.html</eigenwerbung>? Das mag ein (Ansatz) sein, dein Problem zu beheben... -dnh -- Eines Tages wird der Rechner laufen, und an dem Tag gehe ich in Rente ... [Christian Kuhn in suse-linux]

Manfred Tremmel

6 Feb 6 Feb

21:24

Am Dienstag, 5. Februar 2002 23:48 schrieb Axel Heinrici:

...

Aber eines will natürlich trotzdem nicht mehr so richtig. Ich benutze einen soundblaster live. Beim booten erscheint in der Konsole die meldung emu10k1modprobe: can't locate module snd-card-emu10k1 .

Du nutzt Alsa, also brauchst Du auch die Alsa-Module, die sind nicht Teil des Kernels. Für Kernel 2.4.17 benötigst Du die 0.5.12a Treiber, die findest Du unter http://www.alsa-project.org/ Ich konfigurier immer mit ./configure --with-cards=emu10k1 --with-isapnp=no spart ne menge unnötige Module. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ Manfred | http://www.knightsoft-net.de

Thomas Schürmann

11 Feb 11 Feb

07:17

Hallo Axel, Axel Heinrici wrote:

...

Hi

Ich arbeitete mit einer 7.3er Suse mit Kernel 2.4.10 (SuSE-standart-Kernel). Der säuft allerdings gelegentlich ab.

Bei mir auch.

...

... Ich habe heute mal einen 2.4.17er Kernel von ftp.uk.linux.org kompiliert und auch erfolgreich damit neu gebootet.

Ich auch (gestern) ...

...

...

...

Aber eines will natürlich trotzdem nicht mehr so richtig. Ich benutze einen soundblaster live.

Hier: SB512PCI.

...

Beim booten erscheint in der Konsole die meldung emu10k1modprobe: can't locate module snd-card-emu10k1 .

Startest du KDE automatisch beim Booten? Es wird nach einem Alsa-Treiber gesucht. Wie hast du im Kontroll-Zenrum den Sound-Treiber eingestellt? Automatisch, OSS oder Alsa? Ich habe automatisch. Bei mir hat er nach Update auf Vanilla-2.4.17 das emu10k1-Kernel-Modul erst automatisch geladen, als ich in der Kernel-Konfig die komplette Sound- Unterstützung "M" statt "Y" gemarkt habe. Ich habe jetzt lediglich noch beim Starten des KDE 2.2.2 das Problem, dass der Start- und Ende-Sound als Maschinengewehr-Salve ertönt, wenn ich den aRrtsD- Dienst disabled habe. Du kannst den Alsa-Sound also wieder entfernen, wenn du willst.

...

Gruß Axel

Dito Thomas -- ./no_signature

8112

Age (days ago)

8121

Last active (days ago)

List overview

Download

17 comments

8 participants

participants (8)

Axel Heinrici
Christoph Maurer
David Haller
Dieter Kluenter
Manfred Tremmel
Michael Raab
Thomas Schürmann
Waldemar Brodkorb