Ober-Pinguin Linus Torvalds klingt nicht erfreut in der Ankündigung von Linux 5.19-rc7 am gestrigen Sonntag. In der vergangenen Woche mussten Patches gegen Retbleed weitere Tests durchlaufen. Das war dadurch bedingt, dass Patches für solch gravierende Sicherheitslücken meist einem Embargo unterliegen, wodurch sie erst spät die üblichen Prüfungen durch die automatisierte Build- und Testinfrastruktur des Kernels durchlaufen. So ergaben sich auch in diesem Fall einige kleine Korrekturen für Sonderfälle.
Retbleed unter Dach und Fach
Es ist bekannt, dass Torvalds den Kernel gerne nach dem siebten Release-Kandidaten veröffentlicht. Das wird aber diesmal nicht gelingen und somit wird es einen 5.19-rc8 geben. Denn Retbleed war nicht der einzige Grund für Mehrarbeit in dieser Woche. Da war noch der Aufreger, dass Intel mit Alder Lake die Intel GuC-Firmware versioniert ist und dabei keine Abwärtskompatibilität unterstützt. Das bedeutet, dass beim Kernel-Upgrade die Unterstützung für die Grafikbeschleunigung nicht mehr funktioniert, wenn nicht gleichzeitig die Firmware aktualisiert wird.
Versionierte Firmware
Bisher scheint unklar, ob es dafür einen Fix gibt oder ob die entsprechenden Patches für 5.19 zurückgenommen werden. Wer Torvalds Einstellung zu Eingriffen in den Userspace kennt, weiß, dass der Patch so nicht rausgehen wird. Hinzu kam, dass auch ein Patch für Btrfs zurückgenommen werden musste, was Torvalds zu diesem späten Zeitpunkt auch nicht erfreuen dürfte. Dementsprechend war seine Einschätzung der vergangenen Woche: »When it rains, it pours«
Noch zwei Wochen bis 5.19
Mit Linux 5.19 ist also in zwei Wochen, am 31. Juli, zu rechnen. Freuen können wir uns unter anderem auf weitere Vorbereitungen für AMD Zen 4, verbessertes Intel-Power-Management, kürzere Ladezeiten für Gäste in Microsofts Hyper-V und insgesamt über eine halbe Million neue Zeilen im Kernel.
> […] in Microsofts Hyper-V und insgesamt über eine halbe Million neue Zeilen im Kernel.
Halbe Million Zeilen? Ist das nicht schon Bloatware?
Sollte nicht mal drüber nachgedacht werden Treiber auszulagern? Nur bei Bedarf im Installationsfall hinzufügen?
Das passiert bereits. Es wird nur das geladen was du benötigst (Module). Deine Distribution erstellt so den Kernel.
So weit ich weiß geht das ja mehr oder weniger: zum Beispiel gibt es generic und huge kernels. Und was die Distros machen ist ohnehin deren Sache — anders gesagt, eigentlich wird immer nochmal was geändert und gepatcht. Bei Distros wie Debian oder Arch z.B. werden Kerneltreiber ja auch in verschiedene Pakete ausgelagert, bei Debian wird dann nochmal in free und nonfree unterschieden. Die Treiber aber aus dem Kernel auszulagern wäre zumimdest meiner Ansicht nach fatal, da der Kernel immer mit der Hardware interagieren muss und man ihm sozusagen die Grundlage wegreißen würde. Außerdem ist der Fakt, dass es häufig eben keinen Treibersalat gibt (Vgl Windows) ein Vorteil. Dass man unfreie Sachen (Binärblobs) rausnehmen, darüber lässt sich streiten.
Es gibt keine Huge Kernels nur Hugepages. Das hat was mit viruteller Speicherverwaltung zutun, wenn ich mich nicht irre.