Re: Interaktion Kernel<->Libs<->Anwendungen

[Markus Demleitner <msdemlei@xxxxxxxxxxxxxxxxxxxx>]

On Sun, Apr 09, 2006 at 01:26:54AM +0200, Stephan Gromer wrote:
> Ich habe frueher auf dem AMIGA in Assembler programmiert.
> Wenn ich dort eine Library-Funktion aufrufen wollte, so habe ich zuerst 
> die Basisadresse der Bibliothek erfragt und dann die gewuenschte Funktion 
> mit einem Offset zu dieser Basisadresse aufgerufen (z.B. jsr -188(a6)). 
> Dieser Offset war fix, d.h. ich konnte mich darauf verlassen, das 
> Updates (die es ja frueher viel seltener gab) mir da keinen Aerger einhandeln.
> 
> Frage: Ist das bei Linux genauso (Ich habe hier von der technischen 
> Umsetzung leider keinen Plan)? D.h. wenn ich einen Kernel neu 
Das ganze ist eine Frage der calling convention, und die haengt von
der Architektur ab.  So, wie du die Frage gestellt hast, laesst sie
sich also nicht fuer "Linux", sondern allenfalls z.B. fuer "Linux/x86"
beantworten -- dort laufen die syscalls, soweit ich weiss, ueber int
0x80.

Aber das ist wahrscheinlich nicht das, was du wissen willst.

> kompiliere, aendern sich dadurch irgendwelche Sprungziele/Bezugspunkte 
> fuer Libraries bzw. externe Module (sprich muss ich diese mit den dann 
> veraenderten, neuen Kernelheaders alle neu kompilieren?).
Die Sprungziele sind alle durch Namen identifiziert.  Dass diese
selbst ueber zwei Releases von Quelle, Compiler oder sonstwas konstant
bleiben, ist hoechst unwahrscheinlich, aber auch nicht wichtig, weil
ld.so (im Fall von Bibliotheken) oder der Modul-Lader (im Fall von
Kernel-Modulen) fuer die Abbildung der Namen auf die passenden
Adressen sorgen.

Das mit den Kernel-Headern ist wieder eine andere Sache -- dabei
gehts darum, dass sich Datenstrukturen, die du zur Kommunikation mit
dem Kernel einsetzt (z.B. Krempel, den du in ioctls packst), dann und
wann aendern.  Gluecklicherweise ist das haeufig so gemacht, dass ein
neuer Kernel auch noch mit alten Headern ganz ordentlich funktioniert
(was aber eigentlich eher als "durch Zufall" zu klassifizieren ist).
Aber das wiederum ist fuer Module ganz egal (die verwenden immer die
Header des Kernels, fuer den sie gebaut werden), waehrend die meisten
Bibliotheken auf die libc aufsetzen, und in dem Moment ist das alles
ein Problem der libc.

> Falls nein, kann ich dann im Regelfall vielleicht sogar begruendet darauf 
> hoffen, dass dies auch bei einem Kernelversionssprung (z.B. 
> 2.6.8->2.6.15) fuer die im aelteren Kernel bereits vorhandenen und extern 
> benoetigten Symbole ebenfalls der Fall ist (nat. vorausgesetzt, die 
> Uebergabeparameter haben sich nicht geaendert)?
Die Symbole solltest du in der Regel haben.  Trotzdem unterstuetzt
Linux aus vielen Gruenden kein stabiles Binaerinterface fuer
Kernel-Module (und ich glaube, dass es dir letztlich um diese geht).
Das ist aber auch nicht sehr schlimm, zumal viele Distributionen mit
allerlei Helferlein kommen, die zusaetzlich benoetigte Module
automatisch mitbauen, wenn man einen neuen Kernel baut, bei Debian
macht das etwa make-kpkg.

Ansonsten waere es vielleicht hilfreich, wenn du verraetst, ob du die
Module selbst schreiben willst oder nur gucken moechtest, dass Module
von Dritten sich in deinem System wohlfuehlen.

Gruesse,

         Markus