Warum wird der Linux-Kernel mit Nicht-Standard-C (gcc-spezifische Funktionen) codiert? [closed]
Lesezeit: 6 Minuten
SCHH
Der Linux-Kernel-Code verwendet “statement-expression” und typeof extension, wodurch er nur unter gcc kompilierbar ist.
Je mehr ich darüber nachdenke, desto mehr ergibt es keinen Sinn.
Es vereitelt den Zweck der Portabilität und Standard-C. (jetzt benötigt Linux-Kernel-Code einen bestimmten Compiler, der gcc-Erweiterungen unterstützt).
War es eine schlechte Designentscheidung oder gab es einen bestimmten Grund dafür, Linux-Kernel-Code spezifisch für gcc zu machen?
BEARBEITEN: Als ich sagte, dass es die Portabilität besiegt, habe ich es in einem anderen Kontext verwendet. Ich dachte, durch die Konformität mit Standard-C würde es von JEDEM Compiler akzeptiert werden, der Standard-C unterstützt (was genau der Zweck der Erstellung eines Standards ist – um alle verschiedenen Dialekte von C zu vereinheitlichen), und daher portabler wäre. Da gcc so beliebt ist und gcc zig Architekturen unterstützt, ist diese Zeile natürlich fast bedeutungslos. Ich frage nur, ob es einen bestimmten Grund dafür gab, nicht dem Standard C zu entsprechen.
Warum ist es seltsam, dass GNU Linux geschrieben wurde, um mit dem GNU Compiler kompiliert zu werden? Wer hat gesagt, dass Linux für die Portierung auf andere Compiler entwickelt wurde?
– Oliver Charlesworth
15. November 2011 um 21:34 Uhr
Bei Linux geht es nicht um Codequalität oder Portabilität. Es geht um die Weltherrschaft.
– Stefan
15. November 2011 um 21:35 Uhr
Das klingt nicht so, als wäre es für SO relevant. Ich weiß nicht genug über den Umfang von Programmierer zu sagen, ob es dorthin verschoben werden soll oder nicht.
– Josh Darell
15. November 2011 um 21:35 Uhr
@OliCharlesworth Der Linux-Kernel ist nicht GNU/Linux, GNU/Linux gibt an, dass die in einer Distribution enthaltenen Kerndienstprogramme die GNU-Implementierungen sind. Es sollte möglich sein, einen Linux-Kernel mit einer anderen Implementierung der Kernprogramme zu verwenden, zB BSD, und das wäre nicht GNU/Linux.
– Kevin
15. November 2011 um 21:40 Uhr
@SHH Sobald das passiert, sind sie keine “gcc-Erweiterungen” mehr. Sie sind “Zeug, das von einigen Leuten benötigt und von einigen Compilern implementiert wird”. Viele frühere gcc-Erweiterungen sind jetzt Standardfunktionen von C99.
– Cnicutar
15. November 2011 um 21:42 Uhr
Matte
Warum sollten sich die Linux-Kernel-Entwickler Sorgen darüber machen, dass ihr Code beispielsweise auf dem Microsoft Visual Studio-Compiler oder den IBM xlC-Compilern funktioniert?
Wenn Sie einen Kernel schreiben, brauchen Sie eine sehr genaue Kontrolle über viel mehr Dinge, wie das genaue Speicherlayout, als Sie es (im Allgemeinen) im Userspace tun. Solche Steuerelemente werden im C-Standard nicht wirklich berücksichtigt (z. B. als implementierungsdefinierte Merkmale belassen), daher sind entweder einige Erweiterungen erforderlich, oder Sie müssen sich auf die Macken des Compilers verlassen.
Es ist eine rationale Entscheidung, bei einem bestimmten Compiler zu bleiben und seine Erweiterungen zu nutzen. Der Code muss nicht über Compiler hinweg portierbar sein – er muss effizient und über verschiedene Hardwareplattformen portierbar sein.
Ich weiß nicht, mit welchen gcc-Erweiterungsfunktionen Sie viel mehr Dinge wie Speicherlayouts präzise steuern oder die Effizienz maximieren können. Ist das nicht die architekturspezifische Aufgabe der Montagesprache? Ich meine, wenn Kernel-Entwickler maximale Effizienz wollten, warum haben sie dann nicht stattdessen Assemblersprachen verwendet? Es sieht so aus, als hätten alle im Kernel verwendeten gcc-Erweiterungen durch Standard C ersetzt werden können (korrigieren Sie mich, wenn ich falsch liege).
– SCHH
15. November 2011 um 21:55 Uhr
Das Schreiben von Assembler ist viel zeitaufwändiger und schwieriger als das Schreiben von C. Selbst im Kernel ist es auf die Bereiche beschränkt, in denen es entweder a) einfach nicht möglich ist, in C auszudrücken, oder b) für sehr spezifische, leistungskritische Codeteile der C-Compiler wird nicht “perfekt”. Einige der verwendeten Erweiterungen könnten wahrscheinlich durch Standard-C ersetzt werden, aber was wäre der Sinn? Wenn es einfacher ist, mit Exts zu schreiben, warum sich die Mühe machen? Denken Sie auch daran, dass sich der C-Standard weiterentwickelt. Einige Erweiterungen werden im Laufe der Zeit von vielen Compilern implementiert, weil sie es sind nützlich. Dann können sie schließlich zum Standard werden
– Matte
15. November 2011 um 22:01 Uhr
Schließlich, und das ist sehr Wichtig: Der Linux-Kernel kümmert sich nicht um Portabilität überhaupt wie gewöhnliche Anwendungen. Sie schreiben die Umgebung, in der sie ausgeführt werden, und stellen sie dem Userspace zur Verfügung. Die Portabilität, um die sich der Kernel kümmert, ist ganz anders von der Portabilität “gewöhnlicher” Anwendungen.
– Matte
15. November 2011 um 22:03 Uhr
@Mat: Der Linux-Kernel kümmert sich sicher um Portabilität, deshalb verwendet er einen Compiler, der portiert wurde und Code für eine Zillion Architekturen generiert.
– ninjalj
15. November 2011 um 23:14 Uhr
Die Beschränkung auf gcc ist wahrscheinlich eher ein Feature als ein Fehler, wenn sie andere Compiler unterstützt hätten, würden die Leute versuchen, den Kernel unter diesen Compilern zu kompilieren, und das wird die Anzahl der verschiedenen Konfigurationen, die der Kernel kompilieren kann, exponentiell vervielfachen andere verwenden Weltraumprogramme. Der Support-Albtraum wäre es wahrscheinlich nicht wert.
– Lüge Ryan
12. Mai 2014 um 22:36 Uhr
Shaun
Hier finden Sie einige gute Hintergrundinformationen zu den verwendeten spezifischen Erweiterungen. Es ist nicht wirklich aus der Perspektive des “Warum?” geschrieben, aber es sollte Ihnen einen guten Hintergrund zu den Gründen für die Wahl dieses Ansatzes geben:
Der Linux-Kernel-Code ist ein kompliziertes Stück Software. Je mehr Möglichkeiten gcc ihnen bietet, desto glücklicher wären die Programmierer.
Warum sollten sie sich um Portabilität kümmern? gcc kompiliert Code unter praktisch jeder Hardwarekonfiguration PLUS es bietet ihnen gute Funktionen. Warum sollte es sie interessieren, ob Linux mit einem anderen Compiler kompiliert werden könnte oder nicht?
Heute ist portabler Code für uns ein so weit verbreitetes Konzept, dass wir glauben, dass es überall existieren sollte. Aber das ist nicht der Fall. Wenn beispielsweise ein Compiler Echtzeiterweiterungen für C bereitstellt, würde die NASA ihn ohne Rücksicht auf Portabilität verwenden. Der wichtige Punkt ist, dass die Funktionen zu gut sind, um sie für eine Portabilität zu opfern, die nie verwendet wird (ich meine, wer würde den Kernel zum Beispiel mit MS Visual Studio kompilieren?)
nicht jede von gcc unterstützte hardware ist mit guten funktionen von gcc ausgestattet.
– osgx
15. November 2011 um 21:50 Uhr
Wie meinst du das? Die Merkmale, die ich im Sinn hatte, waren von der Art "statement-expression" and typeof wie der OP gefragt hatte.
– Shahbaz
15. November 2011 um 23:22 Uhr
Ich meine, dass gcc nicht jeder unterstützten Plattform eine gute Leistung bietet.
– osgx
16. November 2011 um 0:27 Uhr
Sobald der Kernel kompiliert ist, hinterlässt er keine “Spuren” seiner Kompilierungsumgebung, die das laufende Kernel-Erlebnis beeinträchtigen könnten.
Ich würde sagen, es ist nur eine Frage der Zweckmäßigkeit. Der Kernel enthält auch Assemblerteile, und Assembler ist auch nicht gerade portabel. Wenn die “Mission” des Kernels darin bestünde, einen Kernel zu schreiben, der auf mehreren C-Compilern kompiliert werden könnte, würde die Beschwerde vielleicht auf aufmerksamere Ohren stoßen.
13531200cookie-checkWarum wird der Linux-Kernel mit Nicht-Standard-C (gcc-spezifische Funktionen) codiert? [closed]yes
Warum ist es seltsam, dass GNU Linux geschrieben wurde, um mit dem GNU Compiler kompiliert zu werden? Wer hat gesagt, dass Linux für die Portierung auf andere Compiler entwickelt wurde?
– Oliver Charlesworth
15. November 2011 um 21:34 Uhr
Bei Linux geht es nicht um Codequalität oder Portabilität. Es geht um die Weltherrschaft.
– Stefan
15. November 2011 um 21:35 Uhr
Das klingt nicht so, als wäre es für SO relevant. Ich weiß nicht genug über den Umfang von Programmierer zu sagen, ob es dorthin verschoben werden soll oder nicht.
– Josh Darell
15. November 2011 um 21:35 Uhr
@OliCharlesworth Der Linux-Kernel ist nicht GNU/Linux, GNU/Linux gibt an, dass die in einer Distribution enthaltenen Kerndienstprogramme die GNU-Implementierungen sind. Es sollte möglich sein, einen Linux-Kernel mit einer anderen Implementierung der Kernprogramme zu verwenden, zB BSD, und das wäre nicht GNU/Linux.
– Kevin
15. November 2011 um 21:40 Uhr
@SHH Sobald das passiert, sind sie keine “gcc-Erweiterungen” mehr. Sie sind “Zeug, das von einigen Leuten benötigt und von einigen Compilern implementiert wird”. Viele frühere gcc-Erweiterungen sind jetzt Standardfunktionen von C99.
– Cnicutar
15. November 2011 um 21:42 Uhr