[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian] Treiber-Kompatibilitaet (war: Re: [Dbian 2.2r3] System-Administration)



Moin Stefan!
Stefan Nobis schrieb am Donnerstag, den 21. Juni 2001:

> > Dann erklär uns doch bitte, oh grosser Kernel-Meister, was du denn genau
> > unter der binären Kompabilität verstehst!
> 
> Binärkompatibiltät meint hier eine fest definierte ABI, die sich nicht ändert

_Application_ Binary Interface? Bleich doch mal im Kernel-Space, danke.

> oder zumindest nur bei Wechsel der Hauptversion, also 2.2 zu 2.4 etc.

Was habe ich geschrieben? Das BI folgt mehr oder weniger der PI und
ist innerhalb einiger Kernel-Versionen grundsätzlich kompatibel.

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

> 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
nötigsten Bugfixes gemacht werden, ist die Binärkompabilität auch
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
die 2.2.er Generation an: viele Module sind im Bereich von 2.2.15..2.2.19
kompatibel.

> neueren Netscape-Versionen benutzen und sogar umgekehrt neue Plugins mit
> älteren Netscape-Versionen. Man muss nicht Netscape und Plugin passend
> füreinander compilieren.

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
nur eine Quelle des Ärgers: mitgeschleppte statische Symbole, die auf
Funktionen verweisen, die es in der anderen Komponente später nicht mehr
gibt. Und dann trift es immer die Unschuldigen, die diese Funktionen gar
nicht verwendet haben ;)

> Verzeichnis schmeißen und gut ist. Ich muss also i.d.R. den Treiber selber
> compilieren (soweit möglich). Hersteller können eben nicht einfach eine
> fertige Treiberdatei bereitstellen (unabhängig davon, ob der Quelltext frei
> zugänglich ist oder nicht). Dadurch wird der einfache Einsatz auf dem Desktop
> für Privatleute erschwert.

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.

MfG,
Eduard.
-- 
I think my Linux is more reliable than my harddrive. The question is what
will crash first.


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

830 eingetragene Mitglieder in dieser Liste.


Reply to: