Moin, From: "Heiner Lamprecht" Sunday, March 03, 2002 10:26 PM

On Sunday, 3. March 2002 20:29, Thilo A. Coblenzer wrote:

...

ich habe gerade versucht, die interne Netzwerkkarte von meinem Notebook zum Laufen zu bekommen. Dazu habe ich mir den (hoffentlich) passenden Treiber von tulip besorgt. Jetzt wollte ich tulip.c compilieren, aber einige Pfade stimmen nicht, oder eher mir fehlern die Dateien. Das ist die Ausgabe des Compilers:

Hast Du es mal mit dem bereits kompilierten Kernelmodul versucht? das würde ich gerne! Ich habe zwar inzwischen die Kernel-Quellen installiert und habe mal testweise ein paar Pfade per Hand geändert, aber es will noch nicht so auf anhieb. Da wären so fertige Module super! Wo gibt es die denn? Ich habe soetwas leider nicht gefunden. Vielleicht habe ich mich mal wieder zu blöd angestellt!

Gruß & Danke Thilo

Moin, From: "Michael Raab" Sunday, March 03, 2002 10:33 PM

at Sun, 3 Mar 2002 20:29:29 +0100 Thilo A. Coblenzer wrote:

...

Ihr seht, mir fehlt ein haufen Zeug. Ich habe allerdings auch nur ein unvollständiges System installiert (daher die Netzwerkkarte).Brauche ich noch irgendwelche rpm's?

Sind die Kernelquellen installiert ? Vielen Dank für die sher schnellen Antworten! Ich muß aber nocheinmal ganz dumm nachfragen: Wo finde ich denn die Kernelquellen? Oder wie heißt das passende RPM?

Gruß & Danke Thilo

Hallo! "Thilo A. Coblenzer" schrieb:

Danke für die eMail. Ich habe das Packet kernel-source.rpm aus d2 installiert. Allerdings habe ich das Problem immernoch. Das meintest Du doch mit "das gesamte Quellpaket des Kernels",oder?

Hmm - ist im kernel-source.rpm auch das inlude-Zeug? Nicht dass SuSE das getrennt hat und es somit zwei Pakete gibt. Schau einfach einmal, ob Du /usr/src/linux/include mit viel Inhalt hast. Wenn Du das hast, dann müsstest Du als nächstes schauen, ob Du auch die entsprechenden Verweise hast. Der Compiler sucht nunmal nicht in /usr/src/linux/include sondern in anderen Verzeichnissen. Und ein paar Links helfen dann zur Not auch noch Wunder. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53

Moin, From: "Konrad Neitzel" Monday, March 04, 2002 8:52 AM

"Thilo A. Coblenzer" schrieb:

...

Danke für die eMail. Ich habe das Packet kernel-source.rpm aus d2 installiert. Allerdings habe ich das Problem immernoch. Das meintest Du doch mit "das gesamte Quellpaket des Kernels",oder?

Hmm - ist im kernel-source.rpm auch das inlude-Zeug? Nicht dass SuSE das getrennt hat und es somit zwei Pakete gibt. Schau einfach einmal, ob Du /usr/src/linux/include mit viel Inhalt hast.

Wenn Du das hast, dann müsstest Du als nächstes schauen, ob Du auch die entsprechenden Verweise hast. Der Compiler sucht nunmal nicht in /usr/src/linux/include sondern in anderen Verzeichnissen. Und ein paar Links helfen dann zur Not auch noch Wunder.

Also ich muß nocheinmal blöd nachfragen: Wo sucht denn der Compiler? Er sucht z.B. linux/kernel.h, jetzt ist das aber ein rel. Pfad. Wo sollte ich denn einen Link setzen? Gruß Thilo

From: "Konrad Neitzel" Monday, March 04, 2002 9:25 AM

"Thilo A. Coblenzer" schrieb:

...

Also ich muß nocheinmal blöd nachfragen: Wo sucht denn der Compiler? Er sucht z.B. linux/kernel.h, jetzt ist das aber ein rel. Pfad. Wo sollte ich denn einen Link setzen? [...] ABER: Diese Links sollten schon bei der Installation gesetzt werden. Also kontrolliere doch erst einmal, ob Du die notwendigen Pakete wirklich installiert hast. Installiere doch einmal das Paket mit den Kernel-Includes! Ok, also in /usr/src/kernel-2.4.10-4GB/include steht viel drin. :-) Es gibt auch diese kernel.h. Bevor ich micht jetzt ans linken mache, wollte ich doch noch nachfragen, in welcher Gruppe die Kernel-Includes liegen. Ich weiß so nachfragen sind lästig, aber ich habe auf dem FTP-Server gesucht und nix gefunden, daß so ähnlich heißt.

Gruß & Danke für die Hilfe Thilo

Hallo, On Mon, 04 Mar 2002, Thilo A. Coblenzer wrote:

# ls /usr/include . .. Hermes bzlib.h crack.h gpm.h pci rpm zconf.h zlib.h zutil.h

Du brauchst noch die symlinks /usr/include/linux, /usr/include/asm: ln -s /usr/src/linux/include/linux /usr/include/linux ln -s /usr/src/linux/include/asm /usr/include/asm -dnh -- VBScript is designed to be a secure programming environment. It lacks various commands that can be potentially damaging if used in a malicious manner. This added security is critical in enterprise solutions. -- support.microsoft.com

Hallo, On Tue, 05 Mar 2002, Philipp Thomas wrote:

On Mon, 4 Mar 2002 16:43:44 +0100, you wrote: ^^^ wer is "you"? ok, diesmal ich ;)

...

Du brauchst noch die symlinks /usr/include/linux, /usr/include/asm:

...

ln -s /usr/src/linux/include/linux /usr/include/linux ln -s /usr/src/linux/include/asm /usr/include/asm

Einspruch, Euer Ehren! ;-)

Stattgegeben ;)

Das hängt von der SuSE Version ab!

Mindestens seit der 7.3, wenn nicht sogar schon mit 7.2 sind /usr/include/linux und /usr/include/asm *keine* Symlinks sondern reale Verzeichnisse, in denen _zur glibc_ passende Kernel-Header installiert sind!

Ok. Daraus folgt also, dass die _glibc_ Header installiert werden sollten, aber da "tulip.c" AFAIK ein Kernelmodul ist... AFAIR sollte Thilo das file also in den Kernel-source-tree kopieren (wobei es IIRC dort eh schon ein "tulip.c" gibt -- weiss nicht so recht was das ganze soll, aber meinet- wegen soll er sich dat Dingens halt kompilieren *eg*).

Das ist auch in Ordnung so, denn Kernelcode hat die Finger von Userspace-Code zu lassen und umgekehrt.

Hier nun einen Symlink zu setzen wäre ein fataler Fehler!

Naja, so fatal nun auch wieder nicht: glibc-2.1.3, gegen 2.2.10 gelinkt (IIRC), /usr/src/{linux,asm} sind symlinks auf die passenden Verz. des aktuell verwendeten Kernels 2.4.16... Ja, ich kenn die Argumente (auch Linus'). Ich hatte da neulich eine interessante Diskussion zu dem Thema auf einer anderen Liste, Fazit war in etwa: der Kernel sollte Symbole (wie die glibc) versionieren, alles andere verursacht in der einen oder anderen Konstallation (zu neue glibc/zu neuer kernel) Probleme. Eine Loesung ist weder das "mitliefern" der Header gegen die die glibc gelinkt wurde (was ist, wenn es das symbol "foo" oder die Funktion "bar" nicht mehr im Kernel gibt? Oder wenn sich das Interface vom syscall "baz" geaendert hat?) noch das verlinken auf den (aktuell) verwendeten Kernel (aus den gleichen Gruenden, nur unter anderen Vorzeichen)... Aber: (und deswegen werde _ich_ weiterhin die symlinks legen!) bei der Variante, bei der die symlinks auf den aktuellen Kernel zeigen, sollte es (spaetestens) _beim linken_ zu Fehlern kommen, und nicht erst (wg. nun "falschem" Header) zur "runtime"... Ein Compiler- oder Linker- Error ist IMO halt einem Runtime-Error (z.B. Kernel-panic) doch deutlich vorzuziehen... Ich will Konflikte (zwischen kernel/glibc) moeglichst frueh "mitbekommen"...

Kernelcode sollte *niemals* auf /usr/include/{linux,asm} zugreifen,

Ack. Aber: "userland-code" sollte ggfs. genau darauf zugreifen (und dies sollten (s.o.) IMO eben diese "falschen" symlinks sein) damit evtl. Konflikte zumindest erkannt werden. Ein passendes Szenario wo Linus' "Dogma", dass diese symlinks falsch sind, laesst sich recht einfach "herbeizaubern"... (f'up2poster?)

sondern:

- für 2.2 -I/usr/src/linux/include - ab 2.4 -I/lib/modules//build/include

zu den Compilerflags hinzufügen. Dann sollte es auch funktionieren.

Full ACK! -dnh -- Denn drinnen war noch ne Ente. Äh! Die Füllung ist aber Zusammengbraten. Macht nix! Wird auch veroputzt. (Mampf, Schlürf, Schmatz,) *umdrehundwegguck* BRÖÖÖÖÖÖHHHHH! Der musste Raus! [WoKo in dag°]

Hallo Philipp, On Wed, 06 Mar 2002, Philipp Thomas wrote:

On Tue, 5 Mar 2002 04:18:33 +0100, you wrote:

...

Ack. Aber: "userland-code" sollte ggfs. genau darauf zugreifen (und dies sollten (s.o.) IMO eben diese "falschen" symlinks sein)

Wozu? Selbst ein so Kernel-nahes Paket wie e2fsprogs verwendet seine eigene Kopie der nötigen Header, greift als *nicht* auf die Kernel-Header zu.

Ok. Dann wiederhole ich mal meine Argumentation aus der anderen Liste ;) Um also beim Beispiel e2fsprogs zu bleiben: Ich hab jetzt nicht nachgeschaut, nehme aber mal an, dass e2fsprogs direkt oder indirekt (via libc) syscalls bzw. Funktionen aus den headern verwendet. Soweit so gut (oder auch schlecht). Nun aendert sich das Interface oder sonstwas... (egal warum). e2fsprogs verwendet weiterhin ("froehlich") die "veralteten" header, die's selber mitbringt... Ich koennte, nach diesem Schema, also die e2fsprogs fuer Kernel 0.x kompilieren[1][2] -- aber ob die mit Kernel 2.4 oder 2.{6,8} oder 3.0 noch funktionieren??? Denn: Wenn nun aber ein Programm der e2fsprogs einen der veraenderten syscalls aufruft, und dieser verhaelt sich nicht wie (laut den headern(sic!)) erwartet, dann hat man ein Problem, und das wird eben erst dann, zur Laufzeit, erkannt... Wenn man Pech hat, ist also die Partitionierung/das FS im Eimer... Ergo: Header beim Programm dabei sind auch keine Loesung, wenn der Kernel nicht zu eben _diesen_ Headern (noch) kompatibel ist. Die Argumente des umgekehrten Falles hat u.a. Linus ausfuehrlich dargelegt, das ist also ebensowenig eine Loesung. Es gibt aber einen Unterschied zwischen diesen Varianten: Wenn man die Header des jew. _aktuell verwendeten_ Kernels verwendet, sollte z.B. ein veraendertes Interface schon beim kompilieren, oder spaetestens beim linken einen Fehler verursachen! Dann weiss man wenigstens, _vor_ dem Einsatz eines Programmes, dass man ein Problem hat! Und kann sich um Updates oder sonstige Abhilfen kuemmern. Nein, ich will kein wg. inkompatibler Header vs. tatsaechlich vorhandener Funktionen "verrueckspielendes" mke2fs, das mir auf der HD rumschreibt! Ein Header ist ja immerhin (primaer, wird aber gern missbraucht) eine Datei, die die Funktionen (und Variablen/Konstanten) _deklariert_, und wenn diese Deklaration falsch ist (d.h. nicht mit der Realitaet ueber- einstimmt[3]), dann hat man ein Problem, das erst zur Laufzeit erkannt wird. Werden hingegen Funktionen falsch (lese: mit dem alten/falschen Interface) verwendet, aber der Header ist "korrekt" bzw. aktuell bzw. entspricht der real verwendeten lib / dem real verwendetem Kernel, dann bekommt man's beim kompilieren/linken mit. Das Beispiel "umgekehrt" ist i.d.R. (wg. der "heiligen Kuh" Abwaerts- kompatibilitaet) deutlicher: Ich hab ne App/nen Modul das (indirekt!) einen syscall verwendet, den's erst in der aktuellen Kernelversion gibt, z.B. 2.4.x. Kompiliere ich (mit einem "alten" Kernel, sagen wie 2.0.x, in dem's diesen syscall noch nicht gibt) die App gegen die "mitgelieferten" (hier also aktuellen!) Header bekomme ich evtl. nicht mal vom Linker ne Fehlermeldung... Kompiliere ich hingegen gegen die Header des real verwendeten Kernels/der real verwendeten lib sollte es Fehlermeldungen hageln... Hm. Als Beispiel eines syscalls koennte vielleicht "__llseek" (bzw. [__]lseek64) taugen... Was vorzuziehen ist? IMO ganz eindeutig die Variante, bei der man die Probleme spaetestens beim linken mitbekommt! Jep, ich fahre hier ne glibc 2.1.3 die gegen Kernel 2.2.10 (oder 2.2.12) gelinkt wurde mit nem Kernel 2.4.16 -- keine Probleme -- das aber nur weil das Kernel-API eben (zum Glueck) recht stabil ist! Und ja, alle seitdem (04/2000) kompilierten Programme laufen tadellos (zumindest was den Kernel/die libc angeht). Und /usr/src/linux war dabei jew. immer ein symlink auf den jew. aktuellen Kernel, u.a. 2.2.14, 2.4.0-test1, -test4 und nun 2.4.16 (und ja /usr/include/{asm,linux} waren jew. symlinks auf /usr/src/linux/include/{asm,linux})... Die Variante funktioniert also definitiv ebenfalls -- solange die Kompatibilitaet des APIs gegeben ist. Aendert sich das API hat man in beiden Varianten ein Problem... IMO die einzige Loesung fuer das Problem waere eine Versionierung des Kernel-APIs a la glibc... Wenn ein Programm/Header dann also die Funktion foo(KERNEL_2.0) will, dann _kann_ man schauen, ob's die noch gibt, ansonsten -> ERROR. Dito fuer (KERNEL_2.2), (KERNEL_2.4) etc. pp... So kann man einen Konflikt auf jeden Fall erkennen, egal ob/welche header ein Programm evtl. mitbringt. Leider kenne ich den Mechanismus, mit dem das in der glibc realisiert wird (noch) nicht gut genug, da sollte aber z.B. vielleicht Thorsten genauer Auskunft geben koennen ;) Fazit: Linus' hat (zum Teil) recht -- andererseits liegt er eben IMO (zum Teil) genauso falsch... Dass es bei ihm (URL zu dem archivierten Thread muesste ich raussuchen) genauso "klappt" wie bei mir (mit der genau anderen Variante), liegt IMO genauso am kompatiblen Kernel-API... (Und ja, _dass_ das Kernel-API so weitgehend stabil/kompatibel ist, halte ich fuer ein "Good Thing" -- nur sollte man's, wie immer, nicht uebertreiben, Negativbeispiele zur zwanghaften Abwaertskompatibilitaet gibt's genug, ich sach nur A20-Gate *eg*)

...

(f'up2poster?)

Och, warum nicht hier?

*g* ok, gern... Aber diese Diskussion ist "alt" und lang -- Deswegen dachte ich, s' waere evtl. besser per PM ;)

Diskussionen "hart am Rande" sind hier ja nicht unüblich und ein Bezug zu SuSE-Linux lässt sich sehr einfach herstellen, da ja die Kernel-Header nur in der SuSE-Variante der glibc2 mit an Bord sind ;-)

*g*

Allerdings wäre ich für ein CC: direkt an mich dankbar, Done. :)

-dnh PS: Bin schon recht muede, ich hoffe ich hab alles "erwischt", und bitte also um ein ggfs. nochmaliges Nachhaken... [1] ich weiss leider nicht, wann ext2 eingefuehrt wurde... Das ganze soll sowieso nur das grundsaetzliche Probelm darstellen ;) [2] mal angenommen, fuer die glibc-Version gilt das gleiche -- das duerfte uebrigens wohl einigen "Konflikten" vorgebeugt haben, dass schlicht die libc zu alt war... *eg* Meine Argumentation gilt aber gerade auch fuer die libc, wo das Thema ja zu besonders heftigen Auseinandersetzungen gefuehrt hat... [3] Ja, man koennte sich die glibc 2.2 header installieren -- und weiter die libc <= 4.x verwenden -- dem Compiler is das wurscht... Und so lange es keine "unresolved symbols" gibt, faellt das wohl auch dem Linker nicht auf... -- 282: Perl Der geglückte Versuch, einen braindump direkt ausführbar zu machen. (gefunden von Alexander Schreiber)