Warum wird der Linux-Kernel mit Nicht-Standard-C (gcc-spezifische Funktionen) codiert? [closed]

Lesezeit: 6 Minuten

Benutzer-Avatar
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


Benutzer-Avatar
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


Benutzer-Avatar
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:

https://developer.ibm.com/tutorials/l-gcc-hacks/

  • Wow, danke für den tollen Artikel.

    – SCHH

    15. November 2011 um 22:08 Uhr

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.

1353120cookie-checkWarum wird der Linux-Kernel mit Nicht-Standard-C (gcc-spezifische Funktionen) codiert? [closed]

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy