Re: [Debian] Treiber-Kompatibilitaet (war: Re: [Dbian 2.2r3] System-Administration)
Eduard Bloch <edi@gmx.de> writes:
> > Quelltextkompatibilität und keine Binärkompatibilität, daher gibt es auch den
> > ständigen Ärger mit shared libraries, die in C++ geschrieben sind. Nimm eine
>
> IIRC einer der Gründe, wieso beim Kernel kein C++ verwendet wird!
Nein, das ist nicht das Kernproblem (die Kernelentwickler sagen ja inkl. Linus
selbst ganz explizit, dass es ihnen ausschließlich um Quelltextkompatibilität
geht und dass sie selbst die nicht immer garantieren können).
Ganz nebenbei: Es gibt auch für C++ Binärschnittstellen.
> > Und das passiert auch im Kernel. Da können Details im Speicherlayout mal
> > geändert werden, so dass zwar bei einer Neucompilierung noch alles
> > funktioniert, aber eben keine Binärkompatibilität vorhanden ist.
>
> Nein, eben nicht. Im Gegensatz zu C++ folgt C mehr oder weniger dem
> Quellcode. Wenn die PI sich "eingeschwungen hat", d.h. im Kernel nur die
Nein. Wenn ich ein struct habe und die Reihenfolge zweiter Member wechsle,
dann bleibt die Quellcodekompatibilität bestehen, aber die Binärkompatibilität
geht kaputt. Und deshalb haben die Kernelentwickler keinerlei Hemmungen,
solche Speicherlayouts hier und da zu ändern. Und das passiert (im Verhältnis
zu Änderungen, die die Quelltextschnittstellen betreffen, relativ häufig).
> vorhanden. Natürlich funktioniert das nicht, wenn z.B. von 2.4.4 auf
> 2.4.5 die Protypen einiger Funktionen geändert werden (zusätzliche
> Args), aber damit schrieb ich extra: so Kernel ab 2.2.0+. Sieh die mal
Das ist doch der Punkt. Ich rede nicht von den Signaturen der
Funktionen. Bitte unterscheide zwischen Quelltext- und Binärkompatibilität.
> die 2.2.er Generation an: viele Module sind im Bereich von 2.2.15..2.2.19
> kompatibel.
Du meinst, du schnappst dir Module, die für 2.2.15 compiliert wurden und setzt
die mit einem 2.2.19 Kernel ein? Das halte ich für eine gewagte These (denn
zumindest bei 2.2.19 hat sich sehr viel bei der VM getan) -- schon mal konkret
ausprobiert?
> Seit wann musst du etwas (bei C, wohlgemerkt) etwas für genau diese
> Version kompilieren? Wenn sich der Compiler nicht geändert hat, sehe ich
Wenn die Binärschnittstelle, d.h. vor allem das Speicherlayout, sich genauso
wenig wie die Quelltextschnittstelle ändert, dann musst du nichts neu
compilieren. Änderst du aber die BI, nicht jedoch die QI, dann musst du neu
compilieren. Änderst du beides, dann musst du auch noch Änderungen am
Quelltext vornehmen.
> nur eine Quelle des Ärgers: mitgeschleppte statische Symbole, die auf
Änderungen von Padding in structs, sonstiger Ärger mit Speicherlayout etc.
> Das Problem wird daduch umgangen, dass man nur ein fertigkompiliertes
> object file mitliefert, das man ggf. in das passend kompilierte Modul
> linken kann. Und das inzwischen auch hinreichend automatisiert,
> abgesehen von komplizierten Lizenz-Politik ist es auch meiner Sicht
> recht akzeptabel.
Ja, ich weiß, so a la NVidia. Und auf der Kernelmailingliste gab/gibt es
Diskussionen, ob man gegen solche Hersteller nicht juristisch vorgehen
kann/sollte.
--
Until the next mail...,
Stefan.
--
-----------------------------------------------------------
Um sich aus der Liste auszutragen schicken Sie bitte eine
E-Mail an debian-user-de-request@lehmanns.de die im Subject
"unsubscribe <deine_email_adresse>" enthaelt.
Bei Problemen bitte eine Mail an: Jan.Otto@Lehmanns.de
-----------------------------------------------------------
833 eingetragene Mitglieder in dieser Liste.
Reply to: