Das stabile Versionsmodell für Linux-Kernel wurde 2005 gestartet, als es festgelegt wurde. dass das bestehende Kernel-Entwicklungsmodell (ein neuer Release alle zwei bis drei Monate) die Anforderungen der meisten Nutzenden nicht erfüllt. Die Nutzer wünschten sich, dass in diesen 2–3 Tagen Fehlerkorrekturen vorgenommen wurden. Monate und bei Linux-Distributionen war es schwierig, die Kernel auf dem neuesten Stand zu halten. ohne Feedback von der Kernel-Community. Im Allgemeinen sollten Sie versuchen, die Sicherheit einzelner Kernels zu sichern, und nach den neuesten Fehlerkorrekturen war ein großer und verwirrend den Aufwand der verschiedenen Personen zu verbessern.
Stabile Kernel-Releases basieren direkt auf dem Releases und sind veröffentlicht werden, je nach externen Faktoren (Jahreszeit, verfügbaren Patches, Wartungsarbeitslasten usw.). Die Nummerierung des Stalls Releases beginnen mit der Nummer des Kernel-Release, wird am Ende hinzugefügt. Der Kernel 4.4 wird beispielsweise von Linus veröffentlicht und sind die auf diesem Kernel basierenden stabilen Kernel-Releases 4.4.1, 4.4.2, 4.4.3 usw. Diese Abfolge wird normalerweise mit der Zahl 4.4.y verkürzt, wenn auf einen stabilen Kernel-Release-Baum. Jede stabile Kernel-Releasestruktur die von einem einzelnen Kernel-Entwickler gepflegt werden, der für die Auswahl des benötigte Patches für die Version und die Verwaltung des Überprüfungs-/Veröffentlichungsprozesses.
Stabile Kernel werden für die Dauer des aktuellen Entwicklungszyklus beibehalten. Nachdem Linus einen neuen Kernel veröffentlicht hat, ist der vorherige stabile Kernel-Releasebaum angehalten und Nutzer müssen zum neueren Kernel wechseln.
Langfristig stabile Kernel
Nach einem Jahr dieses neuen, stabilen Veröffentlichungsprozesses stellten wir fest, dass viele verschiedene Nutzer von Linux wollten, dass ein Kernel länger unterstützt wird als nur einige Monate. Als Antwort wurde der LTS-Kernel-Release (Long Term Supported) mit dem ersten LTS-Kernel (2.6.16), der 2006 veröffentlicht wurde. Seitdem wurde eine neue Der LTS-Kernel wird einmal jährlich ausgewählt und die Kernel-Community sorgt dafür, mindestens 2 Jahre lang gelaufen.
Zum Zeitpunkt der Veröffentlichung dieses Artikels waren die LTS-Kernels 4.4.y, 4.9.y, 4.14.y, Releases 4.19.y, 5.4.y und 5.10.y. Ein neuer Kernel wird wöchentlich veröffentlicht. Aufgrund von die Anforderungen einiger Nutzer und Distributionen erfüllt, sind einige zusätzliche ältere Kernels die von Kernel-Entwicklern in einem langsameren Releasezyklus gepflegt werden. Informationen über alle langfristig stabilen Kernel, wer dafür verantwortlich ist und wie lange sie erhalten Sie auf der kernel.org Releases.
Der LTS-Kernel veröffentlicht im Durchschnitt 6–8 Patches pro Tag, während die normale Stable Kernel-Releases enthalten 10–15 Patches pro Tag. Die Anzahl der Patches schwankt je nach Release angesichts der aktuellen Zeit der entsprechenden Entwicklung Kernel-Release und andere externe Variablen. Je älter ein LTS-Kernel ist, sind weniger Patches verfügbar, da viele der letzten Fehlerbehebungen für ältere Kernel. Je älter ein Kernel ist, desto schwieriger ist es jedoch, den Änderungen, die aufgrund der Änderungen an der Codebasis angewendet werden müssen. Also Auch wenn insgesamt weniger Patches angewendet werden, die an der Verwaltung eines LTS-Kernels beteiligt sind, ist größer als die Aufrechterhaltung des normalen stabilen Kernel ausführen.
Stabile Kernel-Patch-Regeln
Die Regeln dafür, was einem stabilen Kernel-Release hinzugefügt werden kann sind seit der Einführung nahezu identisch und werden im Folgenden zusammengefasst:
- Muss offensichtlich korrekt und getestet sein.
- Darf nicht mehr als 100 Zeilen umfassen.
- Es darf nur ein Problem behoben werden.
- Ein gemeldetes Problem muss behoben werden.
- Kann eine neue Geräte-ID oder eine Eigenart für Hardware sein, aber es kann keine größere neue Funktionalität.
- Muss bereits mit Linus Torvalds zusammengeführt worden sein Baum.
Die letzte Regel: „Muss bereits mit Linus Torvalds zusammengeführt sein“, Tree", verhindert damit die Kernel-Community keine Fehlerbehebungen verpasst. Die Community möchte nie, dass etwas repariert wird. in eine stabile Kernel-Version, die noch nicht im Linus Torvalds- Baum, sodass dass bei einem Upgrade niemals eine Regression angezeigt wird. Dadurch wird verhindert, Probleme, die andere Projekte mit einer stabilen und Entwicklungsabteilung haben können, haben.
Kernel-Updates
Die Linux-Kernel-Community hat ihren Nutzern versprochen, dass kein Upgrade funktioniert in einem früheren Release nicht mehr. Das das Versprechen auch heute noch gilt. Regressionen werden zwar durchgeführt, dies ist jedoch die höchste Priorität haben und entweder schnell behoben werden oder die Änderung die Regression über den Linux-Kernel-Baum schnell rückgängig gemacht werden kann.
Dieses Versprechen gilt sowohl für die inkrementellen stabilen Kernel-Updates, sowie die größeren Updates, die alle drei Monate vorgenommen werden. Die kann die Kernel-Community dieses Promise nur für den Code machen, der in die Linux-Kernel-Baum. Code, der im Kernel eines Geräts zusammengeführt wurde und sich nicht die Releases von kernel.org unbekannt sind und Interaktionen damit können nicht geplant oder gar nicht berücksichtigt werden.
Bei Geräten, die auf Linux basieren und große Patchsets haben, auf neuere Kernel aktualisieren, da zwischen den einzelnen Release (10-14.000 Änderungen pro Release). SoC-Patchsets sind vor allem Probleme bei der Aktualisierung auf neuere Kernel aufgrund ihrer Größe und Änderung des architekturspezifischen und manchmal auch des Kerncodes von Kernelcode. Als dass die meisten SoC-Anbieter die Nutzung der Langzeitsupport-Versionen standardisieren. für ihre Geräte, sodass diese Fehler und Sicherheitsupdates erhalten. direkt aus der Linux-Kernel-Community.
Sicherheit
Bei Kernel-Releases deklariert die Linux-Kernel-Community fast nie bestimmte Änderungen als Sicherheitsupdates. Das liegt an dem grundlegenden Problem Die Schwierigkeit, zu bestimmen, ob eine Fehlerkorrektur ein Sicherheitsupdate ist oder nicht der Schöpfung. Außerdem haben viele Fehlerbehebungen nur sicherheitsrelevante Aspekte. nach einiger Zeit warten. Die Kernel-Community empfiehlt daher, einschließlich aller veröffentlichten Fehlerkorrekturen.
Wenn Sicherheitsprobleme an die Kernel-Community gemeldet werden, werden sie wie folgt behoben: so schnell wie möglich an den Entwicklungsbaum und an die stabile Releases. Wie oben beschrieben, werden die Änderungen fast nie als ein „Sicherheitsupdate“, sondern wie jede andere Fehlerkorrektur für den Kernel aussieht. Dies ist damit betroffene Parteien ihre Systeme vor dem kündigt das Problem an.
Details zum Melden von Sicherheitslücken an die Kernel-Community, um und behoben werden müssen, finden Sie Sicherheitslücken finden Sie im Nutzerhandbuch für den Linux-Kernel unter www.kernel.org.
Da Sicherheitslücken nicht vom Kernel-Team bekannt gegeben werden, Zahlen für Probleme mit dem Linux-Kernel werden in der Regel in Wochen, Monaten und manchmal Jahre nach der Fusion in die stabile Version und die Entwicklung Zweige.
Ein sicheres System
Bei der Bereitstellung von Linux-Geräten sollten alle Kernel-Updates für LTS werden vom Hersteller übernommen und an die Nutzer gesendet. nachdem ein korrekter Test durchgeführt wurde, zeigt das, dass das Update gut funktioniert. Dies hat mehrere Vorteile:
- Die Releases wurden von den Kernel-Entwicklern insgesamt überprüft, nicht in Einzelteile.
- Es ist schwierig zu ermitteln, welche Patches zur Behebung von Sicherheitsproblemen verwendet werden. und welche nicht. Fast jede Version von „Langzeitsupport“ enthält mindestens einen bekannten Sicherheits- und Sicherheitsupdates vor.
- Wenn die Tests ein Problem zeigen, reagiert die Kernel-Entwickler-Community um das Problem schnell zu beheben.
- Versuche, nur die ausgeführten Änderungen herauszufiltern, führen zu einem Kernel Struktur, der sich nicht mehr korrekt mit zukünftigen vorgelagerten Releases zusammenführen lässt.