Fedora Linux Kernel – Übersicht
Aktualisierungsplanung
Der Fedora-Linux-Kernel orientiert sich eng an den Upstream-Kernel-Releases. Die aktuellen Fedora-Kernel-Versionen finden Sie in der Paketverwaltung.
Stabile Veröffentlichungen
Stabile Veröffentlichungen von Fedora erhalten zwei Arten von Kernel-Aktualisierungen.
Stabile Kernel-Aktualisierungen
Die Upstream-Kernel-Community unterstützt die neueste Hauptversion mit stabilen Aktualisierungen (6.y.z-Veröffentlichungen). Diese Aktualisierungen werden etwa einmal wöchentlich veröffentlicht, die Häufigkeit kann jedoch variieren. Sobald die Upstream-Kernel-Community eine stabile Version veröffentlicht hat, erstellt Fedora diese und reicht sie als Aktualisierung bei Bodhi ein. Diese Aktualisierungen verbleiben in der Regel einige Tage in Bodhi zum Testen, bevor sie in die Paketquelle für stabile Aktualisierungen aufgenommen werden.
Aktualisierungen der Kernel-Hauptversion
Der Linux-Kernel veröffentlicht alle paar Monate neue Hauptversionen (6.y-Veröffentlichungen). In diesem Fall aktualisiert Fedora die neue Hauptversion, nachdem einige stabile Versionen des Kernels veröffentlicht wurden. Bei der Einreichung der Aktualisierung in Bodhi wird mehr Zeit für Tests eingeplant als bei stabilen Aktualisierungen, um sicherzustellen, dass keine schwerwiegenden Fehler auftreten.
Entwicklungs-Veröffentlichungen
Zu den Entwicklungsversionen von Fedora gehören Rawhide und die verzweigte Version („Branched“).
Rawhide
Der Rawhide-Kernel ist der aktuellste Git-Snapshot von Linus Torvalds' Upstream-Baum auf kernel.org. In regelmäßigen Abständen (oft täglich) wird ein neuer Snapshot erstellt.
Branched
Verzweigte Veröffentlichungen (Branched) erhalten Aktualisierungen in geringeren Abständen als Rawhide. Zu Beginn einer Branched-Version wird typischerweise eine Vorabversion des Kernels verwendet, daher wird jeder Release Candidate (RC) speziell für Branched-Veröffentlichungen erstellt. Sobald der Kernel veröffentlicht ist, erhält er – genau wie die stabilen Fedora-Veröffentlichungen – stabile Aktualisierungen.
Debug-Kernel
Der Linux-Kernel bietet zahlreiche Konfigurationsoptionen, um die Fehlersuche zu vereinfachen. Da einige dieser Optionen jedoch die Systemleistung beeinträchtigen, sind sie in Fedora nicht immer aktiviert. Wenn die Debugging-Optionen im Paket kernel deaktiviert wurden, wird ein separates Paket kernel-debug erstellt, in dem diese Optionen aktiviert sind.
Stabile und Branched-Kernel
Bei stabilen und Branched-Kerneln sind die Debugging-Optionen immer deaktiviert.
Rawhide
Rawhide-Kernel aktivieren die Debugging-Optionen. Jeder Release-Candidate-Kernel wird jedoch mit deaktivierten Debugging-Optionen kompiliert. Release-Candidate-Kernel sind an ihrem „Release“-Feld erkennbar. Beispielsweise ist kernel-5.19.0-0.rc7.20220722git68e77ffbfd06.56.fc37 ein Release-Candidate-Kernel für Fedora 37.
Regeln
Treiber von außerhalb des Kernel-Baums
Die mit Abstand einfachste Methode besteht darin, den Treiber in Linus' Kernel zu integrieren. Fedora aktualisiert sich ständig auf neuere Versionen des Kernels und übernimmt diese Änderungen somit quasi kostenlos, ohne dass für die Fedora-Kernel-Entwickler ein großer Mehraufwand entsteht.
Das Hinzufügen externer Treiber zum Fedora-Kernel, die nicht vom Upstream-Projekt akzeptiert werden, erfordert einen kontinuierlichen Aufwand für das Fedora-Kernel-Team. Daher versuchen wir, dies nach Möglichkeit zu vermeiden. In den wenigen Fällen, in denen es sinnvoll ist, müssen mehrere Kriterien erfüllt sein.
-
Es muss eine angemessene Nachfrage nach dieser Funktion geben, damit wir die Last übernehmen, den Code so lange zu pflegen, bis er in das Upstream-Projekt gelangt.
-
Grundlegende Plausibilitätsprüfungen werden bestanden (wurde von mindestens einem Fedora-Kernel-Maintainer geprüft).
-
Ein Upstream-Entwickler versucht aktiv, seinen Code in Linus' Projektbaum zu integrieren.
-
Ein Fedora-Entwickler ist dafür verantwortlich, es in Fedora auf dem neuesten Stand zu halten.
-
Verursacht keinen erkennbaren Mehraufwand für die Fedora-Kernel-Entwickler. Code, der ständig korrigiert werden muss, wird in der Regel verworfen.
-
Es werden keine neuen Systemaufrufe oder ähnliche ABI-definierende Merkmale hinzugefügt. Dies dient dazu, Inkompatibilitäten zwischen Distributionen und dem Upstream-Projekt zu vermeiden.
-
Die Art und Weise, wie ein Symbol exportiert wird, muss zunächst vom Upstream-Projekt genehmigt werden. Dies umfasst Folgendes:
-
Hinzufügen eines EXPORT_SYMBOL, um etwas zu exportieren, das zuvor nicht exportiert wurde
-
Ändern eines EXPORT_SYMBOL_GPL in EXPORT_SYMBOL
-
Ändern eines EXPORT_SYMBOL in EXPORT_SYMBOL_GPL
-
-
In den seltenen Fällen, in denen wir Exporte hinzufügen, die nicht im Upstream-Projekt enthalten sind, verwenden wir vorsichtshalber EXPORT_SYMBOL_GPL, um sie zu exportieren. Dies dient unter anderem dazu, Drittanbietermodule davon abzuhalten, diese Symbole zu verwenden (da sie in Zukunft möglicherweise nicht mehr benötigt werden). Die einzige Ausnahme von all dem gilt für neuen, noch nicht in den Upstream-Code integrierten Code. Neue Symbole werden so exportiert, wie es der Autor vorgesehen hat.
Staging
Die Treiber im Staging-Verzeichnis des Linux-Kernels befinden sich bekanntermaßen in einem unvollständigen und fehlerträchtigen Zustand. Das Kernel-Team hält es daher für unsicher, die meisten dieser Treiber zu kompilieren und auszuliefern. Wir haben weder Vertrauen in den bestehenden Code noch die Zeit, bekannte Probleme in den Treibern zu beheben.
Wie bei jeder Richtlinie gibt es auch hier Ausnahmen. Fedora liefert derzeit einige Testtreiber für verschiedene Hardwarekomponenten aus. Damit das Fedora-Kernel-Team einen Testtreiber aktiviert, müssen folgende Bedingungen erfüllt sein:
-
Es muss upstream-seitig eine gründliche Codeüberprüfung und -verbesserung geben. Das bedeutet tatsächliche Fehlerbehebungen und nicht nur stilistische Änderungen.
-
Es muss einen Mitwirkenden geben, der bereit ist, Fehlerberichte entgegenzunehmen und mit den Upstream-Entwicklern zu kommunizieren.
-
Der Beitragende muss aktiv an der Verbesserung des Upstream-Treibers beteiligt sein.
-
Der Treiber darf das Kernel-Team nicht übermäßig belasten. Das bedeutet, dass, wenn der Treiber eine große Anzahl von Fehlerberichten verursacht, Fehlerbehebungen nicht schnell genug im Upstream-Projekt erfolgen.
-
Es muss klar sein, dass der Treiber deaktiviert wird, solange eine dieser Bedingungen nicht erfüllt ist oder die abschließende Erfüllung nicht möglich ist.
Eingebaute Features
Die Fedora-Kernel-Entwickler werden gelegentlich gebeten, Funktionen direkt in den Kernel zu integrieren. Das heißt, die Funktionalität wird in die vmlinux-Binärdatei eingebunden, die auf jedem Fedora-System ausgeführt wird, anstatt als separates Modul kompiliert und nur bei Bedarf geladen zu werden. Da vmlinux auf jedem System geladen wird, tendieren wir dazu, Funktionen so weit wie möglich als Module zu implementieren. Während ein Benutzer den Treiber für eine ATI-Grafikkarte benötigt, ist dies für einen anderen nicht der Fall, und die Integration in den Kernel wäre unnötig.
Es gibt keine festgelegten Kriterien, die exakt bestimmen, ob etwas integriert ist oder nicht, aber im Allgemeinen orientiert man sich an diesen Richtlinien:
-
Diese Option kann nicht als Modul erstellt werden und ist hinreichend weit verbreitet
-
Diese Option ist kein Treiber/Dateisystem und wird von einer Fedora-Standardeinstellung verwendet
-
Bei dieser Option handelt es sich um einen Treiber, der von einer Vielzahl von Geräten verwendet wird (Tastatur-/Maustreiber, VT-Unterstützung)
-
Bei dieser Option handelt es sich um ein Dateisystem, das von allen Rechnern verwendet wird, oder um das Standard-Dateisystem von Fedora (tmpfs, ext4).
Auch hier gilt: Es handelt sich um allgemeine Richtlinien, aber im Großen und Ganzen versuchen wir, die Gesamtgröße des geladenen vmlinux auf einen Kernfunktionsumfang zu beschränken.
Sollten die Fedora-Konfigurationsoptionen Ihren Anforderungen nicht genügen, können Sie den Kernel neu kompilieren und die Optionen nach Ihren Wünschen anpassen. Weitere Informationen finden Sie in der Dokumentation zum Erstellen eines benutzerdefinierten Kernels.
Mitwirken
Wenn Sie Interesse daran haben, zur Entwicklung und Wartung des Fedora-Kernels beizutragen, finden Sie weitere Informationen im Kernel-Wiki.
Mailinglisten
Die Fedora-Kernel-Mailingliste ist ausschließlich für Fedora-bezogene Kernel-Themen gedacht. Dies umfasst Fedora-spezifische Paketierung und Kernel-Konfigurationseinstellungen. Diskussionen über Linux selbst finden Sie auf der Kernelnewbies-Mailingliste oder den Linux-Kernel-Mailinglisten.
Sie können die Mailingliste des Fedora-Kernels abonnieren und das Archiv unter Hyperkitty einsehen.
Want to help? Learn how to contribute to Fedora Docs ›