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

Autor: Markus Demleitner <msdemlei_at_cl.uni-heidelberg.de>
Datum: 12.04.2006
On Wed, Apr 12, 2006 at 04:03:58PM +0200, Stephan Gromer wrote:
> > 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?
Nein.  Das passiert zur Linkzeit.  Wenn du wirklich wissen willst,
wie das gemacht wird, ist die Spezifikation des ELF-Formats eine ganz
gute Quelle (ich such den Link mal vorsorglich nicht raus, das ist
recht harter Stoff).

> > 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
Das ist nicht die schlechteste Strategie in solchen Fällen.  Vor
einiger Zeit hat Timo mal ein backporting-Howto über diese Liste
geschickt, die du bestimmt noch im Archiv findest, aber im Groben
hast du schon gemacht, was da zu tun ist.

> 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.
Das ist harmlos, weil sich die Kernelversion dabei nicht ändert.
Eventuelle Kernel-Module müsstest du dabei natürlich neu bauen, aber
aus deiner Beschreibung schließe ich, dass der "Treiber" nur im
Userspace läuft.

> 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.
Das ist wahrscheinlich harmlos, weil die entsprechenden
Datenstrukturen sich hoffentlich nur gutartig ändern, und wäre
ansonsten eh ein großes Problem, weil die Unverträglichkeit mit der
libc und mithin mit allen Programmen bestünde, die irgendwas in der
Art tun.

Aber: Die kernel-headers, die du installiert, müssen zur *glibc*
passen, nicht zum Kernel.  Warum das so ist, kannst du in unzähligen
Feldzügen nachlesen, die du wahrscheinlich durch googlen nach
"symlink into kernel sources" findest.

Realistisch lasse ich etliche meiner Systeme mit komplett wirren
Kernels laufen, auch deutlich neueren als die Debian-libc
"eigentlich" unterstützt.  Die Leute, die die Schnittstellen zwischen
Kernel und Userspace bauen, sind keine Idioten und auch keine
rücksichtslosen Menschenfresser.  Tatsächlich kommt auch die alte
libc4 noch mit dem Kernel 2.6.irgendwas gut aus.

> 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.
Kurzfassung: Nein, der Krempel müsste weiterlaufen.

Langfassung: Es kann natürlich viel schief gehen, angefangen von
Symbolen, die verschwinden (gutartig, der Krempel läuft nicht und
gibt aussagekräftige Fehlermeldungen) bis hin zu heimlichen und
unverträglichen Änderungen in den Argumentlisten von Funktionen
(bösartig, weil das Programm potenziell Murks macht oder einfach
coredumpt).  U.a. die Versionsverwaltung dynamischer Bibliotheken auf
GNU-Systemen sorgt allerdings dafür, dass das nicht passiert, wenn
sich alle an die Spielregeln halten (und davon kann man für halbwegs
vernünftige Software ausgehen) und es gleich kracht, wenn jemand doch
Murks gemacht hat.

Ich hoffe dabei, dass wir nicht über C++ oder sonstwas reden, das
name mangling macht.  Obwohl: Solang du deinem Compiler treu bleibst,
sollte auch das harmlos sein.

Grüße,

          Markus
Received on Wed Apr 12 16:32:45 2006

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