[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lib-Frage



On 17.Aug 2003 - 04:23:07, Seth wrote:
> Ich hab da eine Verständnisfrage.
> 
> Als ich meinen nvidia Treiber Compilieren wollte, fragte er nach den 
> Kernel-Headern, da er kein passendes Kernelimage finden konnte.

Nee, so ganz ist das nicht richtig. Du hast einen Kernel per Kernelimage
installiert - also nicht selbst kompiliert. Daher hast du nicht die für
deinen Kernel benutzten C-Headerdateien, welche der Treiber aber
benötigt weil die in dem Quellcode des Treibers benutzt werden. Ja der
Treiber hat Quellcode, obwohl er ClosedSource ist, er muss nämlich für
jeden Kernel für den das Modul installiert werden soll eine
Schnittstelle kompilieren zwischen dem Kernel und dem vorkompilierten
Binary.

> Das kann ich nachvollziehen, da mit einem neuen Kernel neue Funktionen 
> kommen (im wahrsten Sinne des Wortes) und der Treiber, welcher ja 
> kompiliert werden muss, muss diese Kennen.

Muss er auch nicht, der Treiber kennt nur die alten Funktionen. Wie
stellst du dir das vor, das er sämtliche Headerdateien einliest und dann
daraus lernt? Nee, er braucht halt einige Kernelfunktionen, die sog.
Signatur dieser Funktionen stehen in den Headerdateien. Mit Signatur ist
damit gemeint der Name der Funktion, der Rückgabewert und die Parameter
die sie übernimmt. Dass muss man in dem C-Quellcode definieren um die
Funktion nutzen zu können.

> Nun hat der Treiber aber noch rumgemeckert, das die Compiler Version 
> (via CRC-Check überprüft) nicht stimmen würde und das deshalb die 
> installation abgebrochen würde.

Ich weiss leider nicht warum er das macht, denn der Binärcode den die
Gnu-Compiler liefern ist zwischen allen Versionen kompatibel die so im
Einsatz sind. Vielleicht gibts da andere Gründe, jedenfalls hatte ich
bisher noch kein Problem damit den Treiber mit gcc-3.3 und den Kernel
mit gcc-3.2 zu kompilieren.

> Ich habe zuerst nicht verstanden, warum der Compiler dabei eine Rolle 
> spielt.
> 
> Ja, ich bin kein Programmierer. ;)
> 
> Da ich aber auch nach Informationen für die glibc gesucht habe, da ich 
> herrausfinden wollte, ob ich nicht einfach alle Versionen Installieren 
> kann, und ich irgendwie keine Download-Sourcen gefunden habe UND auch 
> mal kurz nachgedacht habe, bin ich darauf gekommen, das die jeweiligen 
> Libs wohl mit den jeweiligen Compilern kommen, also nichts 
> "eigenständiges" sind. *pling* :)

So ungefähr, wobei man die libc6 (glibc) nicht in mehreren Versionen
benötigt, die sind untereinander alle voll binär kompatibel. Dagegen
gibts wohl immernoch Programme die die alte libc5 benötigen und die
gibts bei Debian als Paket. Anders hingegen ist das bei den Standard-C++
Bibliotheken, die auch zu dem jeweiligen Compiler gehören. Dort haben
sich in den letzten paar Versionen immer wieder die Binärinterfaces der
damit kompilierten Bibliotheken verändert. Dadurch sind Programme die
mit der Version gcc-2.95 kompiliert wurden nicht mit Bibliotheken
benutzbar die mit dem gcc-3.2 kompiliert wurden. Seit gcc-3.2 ist das
aber wieder stabil, so dass es egal ist ob mit gcc-3.2 oder gcc-3.3
kompiliert. Beim Kernelmodulen ist aber das letztgesagte total egal, da
Kernelmodule in C geschrieben sind, deswegen verstehe ich den Check des
NVidia-Treibers auch nicht.

> Dann stellt sich mir aber noch die Frage, warum der Treiber sich nicht 
> kompilieren ließ, wenn die Funktion an sich, der jeweiligen Funktionen 
> doch die selbe ist.

Was hat er denn an Fehlermeldungen so gebracht?

> Auf einer Seite die ich hier auch gepostet habe, habe ich gelesen das es 
> Kernel-Code und, uhm, naja, nicht-Kernel-Code gibt. ;)

In dem einen Treiber? Nee, es gibt dort allerdings schon fertig
kompilierten Objectcode. Ansonsten ist Kernel-Code genau wie jeder
andere C-Code auch. Allerdings ist es für Programme ein Unterschied ob
sie im sog. Kernelspace oder im Userspace ausgeführt werden. Das heisst
ob es sich um Programme handelt die direkt an den Kernel angebunden sind
und damit auch Kernelinternen Schnittstellen nutzen können oder ob die
Programme die öffentlichen Schnittstellen des Kernel nutzen müssen.

> Somit wären die Libs wiederum Kernelabhängig.

Nö, das wäre ja auch schlimm. Jedesmal wenn eine neue Kernelversion
kommt muss man alle Bibliotheken neu kompilieren iiihhh ;) Der Kernel
definiert halt bestimmte Systemrufe, die z.B. von der Libc6 in
C-Funktionen umgesetzt werden (so ungefähr ist es jedenfalls). Und die
weiteren Bibliotheken nutzen dann die libc6 um z.B. Dateien zu öffnen...

Aber auch die libc6 ist nicht kernel-abhängig, da der Kernel halt
Schnittstellen definiert die sich nicht (oder nur sehr selten) ändern.

> Also, bevor die Mail ein ungewolltes ausmaß annimmt, wäre ich für 
> klärende Links dankbar.

Wüsste ich jetzt so auf Anhieb nix, aber du könntest dir Mal die Doku
unter /usr/share/doc zu gcc und libc6 und die Kernel-Dokumentation
angucken. Auch der Kernelquellcode kann sehr aufschlussreich sein,
natürlich muss man dafür ein wenig C verstehen.

Andreas

-- 
Man glaubt einem Mann von Talent mehr, was er versichert, als was er
beweiset - Hier untersucht man erst seine Beweise, dort ist er einer.
		-- Jean Paul



Reply to: