Embedded Linux: "Die Weltherrschaft ist kein Scherz mehr"

Auf der Embedded Linux Conference Europe (ELCE) in Edinburgh ging es um den gesunden Status quo von Embedded Linux, den eher ungesunden Status der Maintainerschaft und die interessante Überlegung, wann Linux kein Linux mehr ist.

In Pocket speichern vorlesen Druckansicht 65 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Anika Kehrer
  • Dr. Oliver Diedrich

Sony-Mitarbeiter Tim Bird galoppierte auf der Embedded Linux Conference Europe geradezu – begleitet von Kommentaren und diversen Lachern – durch seinen Vortrag "Status of Embedded Linux". In seiner dicht gepackten Zusammenfassung gab er Hinweise auf die wichtigsten Errungenschaften des letzten Jahres, darunter eine ganze Reihe neuer Projekte für freie Grafiktreiber für ARM-Systeme: Lima kümmert sich um die Mali-GPU, Etnaviv um Vivante-GPUs, Grate um Nvidia Tegra und Freedreno für Snappdragon-GPUs von Qualcomm.

eMMC ist laut Bird der neue Speicher-Star in Embedded Devices, was Anpassungen an den Dateisystemen nötig macht (weshalb Samsung an dem Dateisystem F2FS arbeitet). Besonders aufregend sei schließlich die aktuelle "big.LITTLE"-Architektur, die sehr langsame, aber sparsame mit sehr schnellen CPUs kombiniert.

Als Vorsitzender der Linux-Foundation-Arbeitgruppe "Consumer Electronics" legte Bird die geziemende Gerätebegeisterung an den Tag. Sein Abschluss-Statement: Die Embedded-Linux-Industrie ist sehr gesund und im Wachstum begriffen. Vor zehn Jahren noch habe die Community gescherzt, dass man dereinst die Weltherrschaft erringen werde. Heute scherze man nicht mehr – die Sache sei überraschend ernst geworden.

Was das für die diversen Maintainer der Embedded-Linux-Community mit sich bringt, darauf richtete der freie Kernel-Entwickler und Berater Wolfram Sang den Scheinwerfer. Als Maintainer des I2C-Treibers hat ihn die Frage beschäftigt, wie er und andere Embedded-Maintainer eigentlich mit ihrer Arbeit zurechtkommen. Daraus resultierte sein Vortrag "Maintainer's Diary – We Have a Scaling Problem".

Patches brauchen zu lange, findet Wolfram Sang: Das Diagramm zählt auf der X-Achse die Tage, bis ein Patch integriert ist, und auf der Y-Achse die Prozentzahl der Patches.

(Bild: Wolfram Sang)

Sang konnte zum Beispiel zeigen, dass die Zahl der Entwickler stärker zulegt als die Zahl der Committer – was bedeutet, dass viel Training seitens des Maintainers erforderlich ist. Bei einer Stichprobe einiger Treiber (I2C, Watchdog, Net/Ethernet, gpio, mtd, mmc, dma und Video) dauerte es im Schnitt 28 Tage, um 50 Prozent der Patches zu integrieren. Erst nach 84 Tagen – was ungefähr dem Zyklus einer kompletten Kernel-Version entspreche – seien zwischen 90 und 100 Prozent der Patches eingeflossen. Wolfram Sang findet: Das geht zu langsam – die Maintainer kommen offenbar nicht hinterher. Er prognostiziert, dass die Situation sich weiter verschlechtert.

Sang gibt einige Tipps, was Anwender, die Entwickler, Organisationen und Unternehmen sowie die Maintainer selbst besser machen können. Anwender können zum Beispiel auf Listen eingesandte Patches kommentieren und Feedback geben, denn der Maintainer kann gar nicht jeden Patch wirklich prüfen (zum Beispiel aus Mangel der entsprechenden Hardware). Developer ermutigt er, bei Patches ihr Bestes zu geben: Man könne durchaus unerfahren sein, aber für mangelnde Sorgfalt gebe es keine Entschuldigung.

Maintainer schließlich müssten ihren Workflow effizienter machen, indem sie automatisieren und ihre Tools ausreizen. Sich bei dem Workflow anderer Maintainer etwas abzugucken, kann helfen, rät Sang, auch wenn die verwendeten Tools in der Regel subjektive Lieblinge sind. Schließlich nimmt er Firmen und andere Organisationen in die Pflicht: Es sei in Ordnung, wenn angestellte Treiberentwickler den Maintainer Dinge fragen. Es sei aber nicht in Ordnung, wenn der Maintainer für grundlegendes Training sorgen soll.

Als kleinen Ausblick aus der Linux-Embedded-Welt in die allerkleinste Rechnerwelt sorgte der ARM-Mitarbeiter Jonathan Austin. In seinem Vortrag "Linux From Sensors to Servers – When is Linux not Linux?" zeigte er, welche Unterschiede zwischen der Linux-Entwicklung für ARM Cortex-A und Cortex-R einerseits und für die ARM-Cortex-M-Serie andererseits bestehen: Letztere verfügt nämlich über keine Memory Management Unit (MMU). Das hat direkte Auswirkung auf die Programmierung, wie Austin am Beispiel von uClinux für Non-MMU-Systeme referierte. So verwendet uClinux statt ELF das Format BFLT für Binaries. Und natürlich gibt es keine virtuelle Speichererweiterung: Der Hardware-Speicher wird statisch belegt, wenn das Binary geladen wird.

Nach dem Vortrag kamen einige Anwesende am Rand auf die Frage zurück, wann ein Linux denn nun kein Linux mehr sei. Die Antwort, wie man sich einigen konnte, lautet ungefähr so: Linux auf Non-MMU-Systemen ist nicht das Linux, das man kennt. Grund dafür ist unter anderem die im User-Space etwas haklige Speicherverwaltung ist (im Kernel selbst sei der Unterschied gar nicht so wahnsinnig groß, sagte Austin). Außerdem würden uClinux-Systeme und ihre Applikationen oft als ein einziges Image gebaut, was sich ebenfalls von normalen Linux-Systemen unterscheide.

Und schließlich gäbe es in dieser Ecke der Linux-Welt sehr viel weniger Upstream: Im Gegensatz zu der normalen Kernel-Community seien die Hardware-Hersteller von Kleinstsystemen mehr daran interessiert, möglichst billig zu produzieren, anstatt ihre Weiterentwicklungen zurück in den Upstream zu geben. (odi) (odi)