Re[2]: Interaktion Kernel<->Libs<->Anwendungen

[Stephan Gromer <stephan.gromer@xxxxxx>]

Hallo Markus,

Hab vielen Dank fuer Deine ausfuehrliche Antwort. Ich war zwei Tage auf
Dienstreise, wo es Internetzugang geben sollte (gab es auch. Fuer 9
Euro pro Stunde ueber gaaaaaaaaaaaanz schnelles WLAN ;) Also habeich
verzichtet, da ich Teilzeitschwabe bin)

>> die Basisadresse der Bibliothek erfragt und dann die gewuenschte Funktion
>> mit einem Offset zu dieser Basisadresse aufgerufen (z.B. jsr
>> -188(a6)).[...]
> [...]Das ganze ist eine Frage der calling convention, und die haengt von
> der Architektur ab.  So, wie du die Frage gestellt hast, laesst sie

Das es da Architekturunterschiede gibt war mir klar. Ich habe mich
mal wieder schlecht ausgedrueckt. 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 aendert.

>> 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.

Verstehe ich das wirklich richtig, das ich zur Laufzeit ueber einen
Namen zugreife (und nicht ueber 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 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.

> 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.

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 laeuft. Die neuere Version tut es. Ich habe
jetzt eine Backporting fuer (geistig) Arme gemacht und mir ueber einen
Verweis auf die unstable-Repos die entsprechenden Sourcen gezogen und
diese dann unter stable als Packet uebersetzen lassen. Dafuer bedurfte
es aber auch einer zusaetzlichen 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 laeuft diese anstandslos weiter. Mein handgemachtes Packet wuerde von der evtl.
neuen Abhaengigkeitssituation ja nicht merken, weil ich (mangels
Ahnung) keine adaequaten Abhaengigkeiten 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 fuer einen Abteilungsfileserver kein
adaequates Vorgehen. Ausserdem wuerde ich es auch so einfach gerne
verstehen, habe aber bisher keinen mit dem fuer berufstaetige eines
voelligen 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 einaeugige Koenig).

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