Hallo Markus,
Hab vielen Dank für Deine ausführliche Antwort. Ich war zwei Tage auf
Dienstreise, wo es Internetzugang geben sollte (gab es auch. Für 9
Euro pro Stunde über gaaaaaaaaaaaanz schnelles WLAN ;) Also habeich
verzichtet, da ich Teilzeitschwabe bin)
>> die Basisadresse der Bibliothek erfragt und dann die gewünschte Funktion
>> mit einem Offset zu dieser Basisadresse aufgerufen (z.B. jsr
>> -188(a6)).[...]
> [...]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
Das es da Architekturunterschiede gibt war mir klar. Ich habe mich
mal wieder schlecht ausgedrückt. Mir war weniger wichtig WIE man
technisch springt, als zu wissen von wo, d.h. das der Einsprung sich
aus Sicht des aufrufenden Programmes nicht ändert.
>> 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.
Verstehe ich das wirklich richtig, das ich zur Laufzeit über einen
Namen zugreife (und nicht über einen beim Linkvorgang definierten relativen
Bezugspunkt) und die ld.so bzw. Modul-loader daraus den Sprung
entsprechend hinbiegen?
> 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.
> 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.
Es ist eigentlich viel primitiver (ich bin Linuxtechn. immer noch
ziemlicher Newbie): Ich habe eine USV mit dem derzeit in Debian stable
augelieferten Treiber nicht läuft. Die neuere Version tut es. Ich habe
jetzt eine Backporting für (geistig) Arme gemacht und mir über einen
Verweis auf die unstable-Repos die entsprechenden Sourcen gezogen und
diese dann unter stable als Packet übersetzen lassen. Dafür bedurfte
es aber auch einer zusätzlichen neuen Bibliothek, die sich dieses
Zugangs verweigerte. Also habe ich die per Hand gebaut und von Hand in
ein Packet gepackt. Diese Lib wollte beim Compileraufruf die
Kernelheaders haben. Meine Sorge war nun, was passiert wenn
a) es ein Kernel(sicherheits)update gibt.
b) ich einen neuen Kernel bauen will (andere config bei selber Version
oder oder gar andere Version) weil ich z.B. noch eine neue
Controllerkarte einbauen will.
Muss ich dann diese Libs nochmal neu compilieren und reinstallieren
oder läuft diese anstandslos weiter. Mein handgemachtes Packet würde von der evtl.
neuen Abhängigkeitssituation ja nicht merken, weil ich (mangels
Ahnung) keine adäquaten Abhängigkeiten angeben konnte.
Wenn ich Dich richtig verstanden habe, scheint das bei a) kein Problem
zu sein und bei b) nur evtl. im Falle des Versionswechsels.
Bei meinem Trial and Error-Versuch schien es zu funktionieren, aber
Glauben und Hoffen erscheint mir für einen Abteilungsfileserver kein
adäquates Vorgehen. Außerdem würde ich es auch so einfach gerne
verstehen, habe aber bisher keinen mit dem für berufstätige eines
völligen anderen Fachgebietes zeitlichen Aufwand vertretbaren Zugang
zur Thematik gefunden (Anm.: Wer sich jetzt wundert, das ein
Ahnungsloser einen Abteilungsfilserver administriert: Unter den
Blinden ist der einäugige König).
Nochmals vielen Dank!
LG
Stephan
--
Stephan Gromer, MD. PhD.
Work: Biochemie-Zentrum Heidelberg / Im Neuenheimer Feld 504 / D-69120
Heidelberg / Tel.: +49 (6221) 544291 / Fax.: +49 (6221) 545586
Home: Sternallee 89 / D-68723 Schwetzingen / Tel.: +49 (6202) 855038
Mobil: +49 (172) 7694555 / URL: http://www.gromer-online.de
Received on Wed Apr 12 15:59:27 2006