Kernel-Report
Keynote von Jonathan Corbet auf dem Linux-Kongress 2008
Der Freitag, 10. Oktober, begann um 9.30 mit der Keynote »The Kernel Report« von LWN-Herausgeber Jonathan Corbet. Von dieser Keynote sind Vortragsunterlagen (PDF) verfügbar.
Corbet platzierte seine Themen in einem »Challenge-Response«-Schema. Er stellte jeweils eine aktuelle Herausforderung für die Kernel-Entwicklung vor und zeigte auf, welche Lösungen oder Lösungsansätze es gibt. Bei einem kurzen Überblick über die letzten Kernel-Versionen konnte Corbet verkünden, dass wenige Stunden zuvor Linux 2.6.27 offiziell erschienen war.
Die erste Herausforderung ist laut Corbet, die hohe Entwicklungsgeschwindigkeit aufrecht zu erhalten. Die Lösung hierfür ist Linux-next, eine Art Testkernel, der eine Vorschau auf die übernächste offizielle Linux-Version gibt.
Auch die hohe Qualität von Linux soll natürlich erhalten bleiben. Wünschenswert wären Kernel-Veröffentlichungen, die keine Regressionen enthalten. Dieses Ziel ist unrealistisch. Gleichgültig wann eine neue Version veröffentlicht wird, einige Fehler werden immer erst danach gefunden oder behoben. Neuerdings gibt es Tools zum Sammeln der Fehlerberichte auf kerneloops.org. Die vorliegenden Zahlen zeigen, dass die meisten Probleme nur wenige Anwender betreffen. Fehler, die viele Anwender betreffen, werden oft von proprietären Modulen verursacht. Sie werden auch sehr schnell korrigiert, oft noch in Testkerneln. Ein gewisser sozialer Druck auf die Entwickler und strenge Regeln für die Aufnahme von Patches in den Kernel sollen dafür sorgen, dass auch andere Fehler zügig behandelt werden.
Eine weitere Herausforderung sind die verschiedenen Interessen der unterschiedlichen Entwicklergruppen. Manche Entwickler bei verschiedenen Firmen wollen ihren Code so schnell wie möglich zu den Anwender bringen. Diverse Distributionen fügen daher Patches zu ihren Kernels hinzu, die noch nicht im offiziellen Kernel sind. Ausdrücklich erwünscht ist es aber, dass alle Änderungen zuerst im offiziellen Kernel erscheinen sollten.
Code, der außerhalb des offiziellen Kernels existiert, stellt eine weitere Herausforderung dar. Er weist eine tendenziell schlechtere Qualität als der offizielle Kernel-Code auf. Proprietäre Module sind ebenfalls Teil dieses Problems. Manchmal haben Entwickler aufgrund enger Projekttermine auch keine Zeit, ihren Code für die Aufnahme in den offiziellen Kernel anzubieten. Die Reaktion der Kernel-Entwickler ist Aufklärung der externen Entwickler, wie sie ihren Code am effektivsten in den Kernel einbringen können. Vom Schreiben von proprietären Modulen wird abgeraten.
Die Sicherheit ist eine weitere Herausforderung, und zwar im Kernel selbst sowie in Anwendungen. 2008 gab es bisher 41 CVE-Meldungen, die den Kernel betreffen. Eine Lösung hat Corbet nicht parat. Die bereits genannten Methoden zur Verbesserung der Codequalität können auch hier helfen. Bei der Sicherheit der Anwenderprogramme kommen Systeme wie SELinux oder neuerdings Smack ins Spiel. Daneben gibt es einige weitere Systeme. Gar nicht erwähnt wurde beispielsweise RSBAC, dessen Funktionalität sich mit SELinux überschneidet. Der Hauptentwickler von RSBAC, Amon Ott, war als Besucher der Konferenz anwesend, hatte jedoch aus Zeitgründen keinen Vortrag eingereicht.
Die Verbesserung der Skalierbarkeit ist eine fortwährende Herausforderung für die Kernel-Entwickler. Da Sperren oft tödlich für die Performance sind, wird ständig an feineren Sperren und Algorithmen ohne Sperren gearbeitet. Auch Cache-Effekte müssen immer mehr berücksichtigt werden.
Der Speicherverbrauch ist insbesondere für kleine eingebettete Systeme ein Problem. Zwischen Version 2.6.13 und 2.6.26 wurde die minimale Kernelgröße, die erreichbar war, immer größer. Bessere Datenstrukturen und mehr Optionen für kleine Systeme sollen dies wieder korrigieren. Dafür wird allerdings mehr Mitarbeit aus dem Bereich der eingebetteten Systeme benötigt.
Speicher- und Dateisysteme wurden auch in anderen Vorträgen angesprochen. Herkömmliche Dateisysteme waren auf vergleichsweise kleine Geräte und Dateien ausgelegt, was durch ihr Alter bedingt ist. Es gibt oft zuviele Verwaltungsstrukturen, die den Speicherbedarf auf dem Gerät sowie im RAM hochtreiben, und die Zeit eines Dateisystem-Checks wird zu lang. ext4 wird mit seinen Extents alle Begrenzungen aufheben und Metadaten mit Prüfsummen schützen. btrfs wird mit Extents, Subvolumes, Snapshots und vollständigen Prüfsummen aufwarten.
Solid State Devices (SSD) sind der neue Trend bei Massenspeichern und können in bestimmten Nischen Festplatten bereits verdrängen. Die aktuellen Dateisysteme sind bezüglich dieser Geräte veraltet, doch das im nächsten Jahr kommende btrfs wird dafür geeignet sein. Ebenso ubifs, das in Kernel 2.6.27 erstmals enthalten ist und einen direkten Zugriff auf das Flash (im Gegensatz zu USB oder einer Emulation der ATA- oder SCSI-Schnittstelle) voraussetzt.
Auch die Hardware-Unterstützung stellt eine fortgesetzte Herausforderung dar. Vieles wurde besser, Beispiele sind AMD, Atheros und VIA. Das Problem WLAN ist weitgehend gelöst. Doch die Grafik macht noch viel Arbeit. Auch in die Energieverwaltung ist noch viel Arbeit zu stecken. Wer die Entwickler unterstützen will, sollte laut Corbet proprietäre Treiber, unkooperative Hersteller und die zugehörige Hardware meiden.
Die Unterstützung für harte Echtzeit existiert mit dem Realtime-Patchset bereits außerhalb des Kernels. Echtzeit-Gruppen-Scheduling wurde in Linux 2.6.27 stabilisiert, eine Menge anderer Dinge sind noch zu integrieren.
Auch der Netzwerk-Stack benötigt weitere Pflege. Wireless und IPv6 müssen noch verbessert werden. Eine weitere Herausforderung stellt die Virtualisierung dar. Für Corbet ist von den verfügbaren Hypervisoren KVM der derzeit aktivste, ihm dürfte die Zukunft gehören. Auch Container gehören zur Virtualisierung. Viel Code wurde schon in den Kernel geholt. Änderungen für sysfs, Checkpoints und Unterstützung der Verwaltung warten noch auf ihre Integration.
Tracing wurde besonders von Großanwendern schon lange gefordert, ist aber immer noch nicht vollständig realisiert. Das recht fortgeschrittene Systemtap ist sehr schwer zu benutzen. Es beherrscht zwar dynamisches Tracing, kann jedoch keine Userspace-Programme tracen. Das neue ftrace ist eher für Kernelentwickler gedacht. Eine Alternative stellt LTTng (Linux Trace Toolkit) dar. Dass sich eine direkte Portierung von DTrace von Solaris aus Lizenzgründen verbietet, dürfte klar sein. Daneben könnten auch andere grundlegende Unterschiede in den Systemen verhindern, dass man DTrace so einfach übernehmen kann.
Eine Video-Aufzeichnung der Keynote steht mittlerweile beim Linux-Magazin zur Verfügung.
