Seite 2: Kernel-Log-Staccato: Kernel

Inhaltsverzeichnis

Kernel-Log-Staccato

Kernel

• Nach den langen, im Kernel-Log oder bei LWN.net (u. a. 1, 2, 3) mehrfach erwähnten Diskussion um die Aufnahme des für Android entwickelten Suspend Block API (früher Wakelocks) ging das Thema Anfang des Monats auf der LKML in die nächste Runde: Paul E. McKenney hat versucht, die Problematik und die früheren Diskussionen zusammenzufassen. Die daraus entstandene Diskussion dauert noch an; die mittlerweile dritte, als "final" bezeichnete Ausgabe der Zusammenfassung gibt allerdings einen guten Überblick darüber, welche Probleme die Entwickler zu lösen versuchen und wo die Schwierigkeiten dabei liegen.
• Con Kolivas hat die auf Linux 2.6.35 abgestimmte Version 0.323 seines Brain Fuck Scheduler (BFS) freigegeben, den er bei seinem eigenen, auf "Reaktionsgeschwindigkeit und Interaktivität" optimierten Kernel 2.6.35-ck1 einsetzt; mit Messergebnissen zu seinem Prozess-Scheduler und seinem Kernel versucht er deren Vorteile zu unterstreichen. Allerdings scheint er die anderen Kernel-Entwickler aber mehr über sein Vorgehen zu informieren, als mit ihnen zusammenzuarbeiten. Das wäre jedoch nötig, um Teile seiner Verbesserungen für eine Aufnahme in den Kernel fit zu machen oder dabei zu helfen, den derzeit im Kernel enthaltenen Scheduler und andere Subsysteme zu verbessern – nur so könnte der Standardkernel in den Bereichen besser werden, in denen der Code von Kolivas möglicherweise Vorteile zeigt.
• LWN.net hat kürzlich den englischen Artikel Realtime Linux: academia v. reality veröffentlicht, in dem der deutsche Realtime-Linux-Entwickler Thomas Gleixner einige Hintergründe zur Entstehung der Realtime-Erweiterungen für den Linux-Kernel liefert und dabei auch auf einige Aspekte bei der Zusammenarbeit mit Universitäten und anderen Forschern eingeht. In dem Artikel findet sich auch eine Liste mit zahlreichen in den letzten Jahren entstandenen Kernel-Verbesserungen, die ihren Ursprung im RT-Zweig haben.
• In verschiedenen Webforen und auf Mailinglisten finden sich Berichte, dass sich Systeme unter bestimmten Bedingungen extrem langsam anfühlen oder zeitweise gar nicht mehr reagieren, während der Kernel größere Datenmengen auf ein langsames Medium (etwa einen USB-Stick) schreibt. Ein Entwickler hat sich diesem Problem jetzt gewidmet und einige Änderungen zur Diskussion gestellt, die ein in der Beschreibung des ersten Patches näher erläutertes Problem beseitigen sollen. Es ist derzeit allerdings noch ungewiss, ob diese Änderungen noch in Linux 2.6.36 einziehen.
• Kurz nach den Ausführungen zur Fehlerbeseitigung und Qualitätssicherung im letzten regulären Kernel-Log schlug jemand im Bezug auf eine der erwähnten Mails von Theodore 'tytso' Tso vor, doch bei 2.6.36 keine neuen Funktionen aufzunehmen und stattdessen nur Fehlerkorrekturen zu akzeptieren, bis die Liste der bekannten Fehler abgearbeitet sei. Tytso erklärte in seiner Antwort, dass man dies bereits versucht habe und es nicht funktioniere – unter anderem weil die Entwicklung von Freiwilligen betrieben würde, die in einer solchen Periode trotzdem Verbesserungen entwickeln und diese dann eben erst mal für sich behalten. Wenn all die aufgestauten Änderungen später in den Kernel aufgenommen würden, brächte das noch viel mehr Fehler mit sich. Er schließt mit den Worten, es sei letzten Endes selbstzerstörerisch, die Aufnahme neuer Funktionen unterbinden zu wollen ("But trust me, trying to forbid new features in mainline is ultimately self-defeating.").
• Im Artikel "Speaking UNIX: Get to know Ksplice" erläutert IBM-Developerworks die Funktionsweise von Ksplice näher, mit dem sich Sicherheitslücken im Kernel ohne Neustart korrigieren lassen.
• IBM-Entwickler Ben Chociej hat einige als "Btrfs hot data tracking functionality" gezeichnete Erweiterungen veröffentlicht, durch die das experimentelle Dateisystem viel genutzte Daten auf einem schnellen Medium eines Datenträgerverbungs ablegt und alle anderen auf einem langsameren, um die Zugriffsgeschwindigkeit auf die häufiger benötigten Daten zu steigern.