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

Autor: Markus Demleitner <msdemlei_at_cl.uni-heidelberg.de>
Datum: 10.04.2006
On Sun, Apr 09, 2006 at 01:26:54AM +0200, Stephan Gromer wrote:
> Ich habe früher 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 gewünschte 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 früher viel seltener gab) mir da keinen Ärger 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 hängt von
der Architektur ab.  So, wie du die Frage gestellt hast, lässt sie
sich also nicht für "Linux", sondern allenfalls z.B. für "Linux/x86"
beantworten -- dort laufen die syscalls, soweit ich weiß, über int
0x80.

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

> kompiliere, ändern sich dadurch irgendwelche Sprungziele/Bezugspunkte 
> für Libraries bzw. externe Module (sprich muss ich diese mit den dann 
> veränderten, neuen Kernelheaders alle neu kompilieren?).
Die Sprungziele sind alle durch Namen identifiziert.  Dass diese
selbst über zwei Releases von Quelle, Compiler oder sonstwas konstant
bleiben, ist höchst unwahrscheinlich, aber auch nicht wichtig, weil
ld.so (im Fall von Bibliotheken) oder der Modul-Lader (im Fall von
Kernel-Modulen) für 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 ändern.  Glücklicherweise ist das häufig 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 für Module ganz egal (die verwenden immer die
Header des Kernels, für den sie gebaut werden), während 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 begründet darauf 
> hoffen, dass dies auch bei einem Kernelversionssprung (z.B. 
> 2.6.8->2.6.15) für die im älteren Kernel bereits vorhandenen und extern 
> benötigten Symbole ebenfalls der Fall ist (nat. vorausgesetzt, die 
> Übergabeparameter haben sich nicht geändert)?
Die Symbole solltest du in der Regel haben.  Trotzdem unterstützt
Linux aus vielen Gründen kein stabiles Binärinterface für
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 zusätzlich benötigte Module
automatisch mitbauen, wenn man einen neuen Kernel baut, bei Debian
macht das etwa make-kpkg.

Ansonsten wäre es vielleicht hilfreich, wenn du verrätst, ob du die
Module selbst schreiben willst oder nur gucken möchtest, dass Module
von Dritten sich in deinem System wohlfühlen.

Grüße,

         Markus
Received on Mon Apr 10 11:57:08 2006

Dieses Archiv wurde generiert von hypermail 2.1.8.
Zurück zur UUGRN-Homepage.