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.
