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