Heim  >  Artikel  >  System-Tutorial  >  Der Vater von Linux konnte endlich überzeugt werden: Die 30 Jahre alte C-Sprache des Linux-Kernels wird auf C11 aktualisiert

Der Vater von Linux konnte endlich überzeugt werden: Die 30 Jahre alte C-Sprache des Linux-Kernels wird auf C11 aktualisiert

WBOY
WBOYnach vorne
2024-02-14 21:36:03373Durchsuche

Es gibt kürzlich Neuigkeiten, dass die verwendete Version des C-Sprach-Linux-Kernels von 1989 endlich ein großes Upgrade erhalten hat. Das Tempo der modernen Technologie ist unaufhaltsam. Heute hat die Linux-Open-Source-Community einen überzeugenden Plan angekündigt, die C-Sprachversion des Kernels auf den C11-Standard zu aktualisieren. Es wird erwartet, dass diese große Reform nach der Linux-Version 5.18, also im kommenden Mai, in Kraft treten wird. Dieser wichtige Schritt wird dem Linux-Kernel unbegrenzte potenzielle Möglichkeiten eröffnen und ihm helfen, sich besser an die Anforderungen moderner Technologien anzupassen.

Diese Entscheidung kam plötzlich. Es dauerte nur eine Woche von der Einleitung der Frage bis zur offiziellen Stellungnahme. Es ist nicht einfach, Linus Torvalds, den hartnäckigen Vater von Linux, zu überzeugen. Der Grund dafür scheint ein wenig zufällig zu sein. Linux 之父终于被劝动:用了 30 年的 Linux 内核 C 语言将升级至 C11

Die Kettenreaktion eines Käfers

Das Problem entstand letzte Woche in einer Linux-Community-Diskussion.

Ein Doktorand namens Jakob Koschel entdeckte ein solches Problem, als er sich mit der Verhinderung spekulativer Ausführungsschwachstellen im Zusammenhang mit Kernel-Linked-List-Primitiven befasste.

Der Linux-Kernel nutzt in großem Umfang doppelt verknüpfte Listen, die durch struct list_head

: definiert sind

struct list_head {
    struct list_head *next, *prev;
    };
Diese Struktur ist oft in andere Strukturen eingebettet. Auf diese Weise können verknüpfte Listen mit jedem relevanten Strukturtyp erstellt werden.

Darüber hinaus bietet der Kernel auch eine große Anzahl von Funktionen und Makros, mit denen verknüpfte Listen durchlaufen und betrieben werden können. list_for_each_entry() ist eines davon, ein als Kontrollstruktur getarntes Makro. Das Problem liegt in diesem Makro. Gehen Sie davon aus, dass der Kernel die folgende Struktur enthält:

struct foo {
        int fooness;
    struct list_head list;
    };
Die Elemente in

list können verwendet werden, um eine doppelt verknüpfte Liste der foo-Struktur zu erstellen. Angenommen, es gibt eine Struktur namens foo_list, die als Kopf einer solchen verknüpften Liste deklariert ist. Diese verknüpfte Liste kann mit dem folgenden Code durchlaufen werden:

struct foo *iterator;

    list_for_each_entry(iterator, &foo_list, list) {
        do_something_with(iterator);
    }
    /* Should not use iterator here */

Das Listenargument teilt dem Makro den Namen der list_head-Struktur innerhalb der foo-Struktur mit. Diese Schleife wird einmal für jedes Element in der Liste ausgeführt, wobei der Iterator auf dieses Element zeigt. Dies führte zu einem Fehler im USB-Subsystem: Der an das Makro übergebene Iterator konnte nach dem Beenden des Makros weiterhin verwendet werden.

Das ist eine gefährliche Sache, deshalb hat Koschel einen Fix eingereicht, der den Fehler behebt, indem er die Verwendung des Iterators nach der Schleife stoppt.

Linux 之父终于被劝动:用了 30 年的 Linux 内核 C 语言将升级至 C11Überzeuge Linus

Aber Linus Torvalds selbst gefällt dieser Patch nicht besonders und sieht keinen Zusammenhang mit der Sicherheitslücke bei der spekulativen Ausführung. Nachdem Koschel es ausführlich erklärt hatte, gab Linus zu, dass es sich lediglich um einen häufigen Fehler handele.

Allerdings waren die Dinge nicht so einfach und Linus erkannte bald die wahre Ursache: Der Iterator, der an das Durchlaufmakro für verknüpfte Listen übergeben wird, muss in einem Bereich außerhalb der Schleife selbst deklariert werden. Dieser nicht prädiktive Fehler tritt auf, weil es in C89 keine Funktion zum Deklarieren von Variablen in Schleifen gibt.

Makros wie list_for_each_entry() lassen im Grunde immer den letzten HEAD-Eintrag außerhalb der Schleife verloren, einfach weil wir keine Iteratorvariablen in der Schleife selbst deklarieren können.

Wenn Sie ein Iteratorlisten-Traversal-Makro schreiben könnten, das sich selbst deklarieren könnte, wäre der Iterator außerhalb der Schleife nicht sichtbar und es würden keine derartigen Probleme auftreten. Da der Kernel jedoch am C89-Standard festhält, können Variablen nicht innerhalb einer Schleife deklariert werden.

Linus hat beschlossen, lasst uns ein Upgrade durchführen. Vielleicht ist es an der Zeit, auf den C99-Standard umzusteigen. Es ist zwar ebenfalls über 20 Jahre alt, aber mindestens neuer als C89 und ermöglicht die Deklaration von Variablen innerhalb einer Schleife.

Da C89 so alt ist, warum hat es sich nach so vielen Jahren nicht geändert? Linus sagte, das liege daran, dass wir in einigen alten GCC-Compiler-Versionen auf einige seltsame Probleme gestoßen seien und nicht beiläufig aktualisiert werden könnten.

Jetzt hat der Linux-Kernel jedoch die Mindestanforderung für gcc auf Version 5.1 angehoben, sodass diese seltsamen Fehler in der Vergangenheit verschwunden sein sollten. Linux 之父终于被劝动:用了 30 年的 Linux 内核 C 语言将升级至 C11

Arnd Bergmann, ein weiterer Kernentwickler, glaubt, dass wir definitiv auf C11 oder sogar höher upgraden können. Durch ein Upgrade auf C17 oder C2x wird jedoch die Unterstützung für gcc-5/6/7 unterbrochen, sodass ein Upgrade auf C11 einfacher zu erreichen ist.

Am Ende war Torvalds mit der Idee einverstanden: „Okay, erinnern Sie mich, versuchen wir es früh im 5.18-Merge-Fenster.“ Der Wechsel zu C11 könnte zu unerwarteten Fehlern führen, aber wenn alles gut geht, wird das nächste Linux The Die Kernel-Version wird offiziell auf C11 umgestellt.

Das obige ist der detaillierte Inhalt vonDer Vater von Linux konnte endlich überzeugt werden: Die 30 Jahre alte C-Sprache des Linux-Kernels wird auf C11 aktualisiert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:lxlinux.net. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen