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

[Markus Demleitner <msdemlei@xxxxxxxxxxxxxxxxxxxx>]

On Wed, Apr 12, 2006 at 04:03:58PM +0200, Stephan Gromer wrote:
> > 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?
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 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
Das ist nicht die schlechteste Strategie in solchen Faellen.  Vor
einiger Zeit hat Timo mal ein backporting-Howto ueber 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 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.
Das ist harmlos, weil sich die Kernelversion dabei nicht aendert.
Eventuelle Kernel-Module muesstest du dabei natuerlich neu bauen, aber
aus deiner Beschreibung schliesse ich, dass der "Treiber" nur im
Userspace laeuft.

> 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 aendern, und waere
ansonsten eh ein grosses Problem, weil die Unvertraeglichkeit mit der
libc und mithin mit allen Programmen bestuende, die irgendwas in der
Art tun.

Aber: Die kernel-headers, die du installiert, muessen zur *glibc*
passen, nicht zum Kernel.  Warum das so ist, kannst du in unzaehligen
Feldzuegen 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" unterstuetzt.  Die Leute, die die Schnittstellen zwischen
Kernel und Userspace bauen, sind keine Idioten und auch keine
ruecksichtslosen Menschenfresser.  Tatsaechlich 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 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.
Kurzfassung: Nein, der Krempel muesste weiterlaufen.

Langfassung: Es kann natuerlich viel schief gehen, angefangen von
Symbolen, die verschwinden (gutartig, der Krempel laeuft nicht und
gibt aussagekraeftige Fehlermeldungen) bis hin zu heimlichen und
unvertraeglichen Aenderungen in den Argumentlisten von Funktionen
(boesartig, weil das Programm potenziell Murks macht oder einfach
coredumpt).  U.a. die Versionsverwaltung dynamischer Bibliotheken auf
GNU-Systemen sorgt allerdings dafuer, dass das nicht passiert, wenn
sich alle an die Spielregeln halten (und davon kann man fuer halbwegs
vernuenftige Software ausgehen) und es gleich kracht, wenn jemand doch
Murks gemacht hat.

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

Gruesse,

          Markus