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.
