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 [EMAIL PROTECTED] die im Subject "unsubscribe <deine_email_adresse>" enthaelt. Bei Problemen bitte eine Mail an: [EMAIL PROTECTED] ----------------------------------------------------------- 830 eingetragene Mitglieder in dieser Liste.
