Grün ist Leben

Inhaltsverzeichnis

Da der Linux-Vater Linus Torvalds auf der Gehaltsliste der Prozessoren-Schmiede Transmeta steht, verwundert es nicht sonderlich, dass die Kalifornier vor kurzem eine erste Betaversion ihrer Embedded Linux Distribution veröffentlicht haben. Dass diese - angesichts der Prozessoren-Bezeichnung ‘Crusoe’ - nicht ‘Friday’, sondern ‘Midori’ - japanisch für Grün - heißt, soll Transmetas Anstrengungen unterstreichen, das Linux-System energiesparend zu gestalten. Die Bemühungen spiegeln sich auch in der bevorzugten Prozessorplattform wider - dem x86-kompatiblen Crusoe-Chip -, der dank spezieller Technik sparsam mit Energie umgeht und sich damit perfekt für tragbare Internet-Geräte eignet.

Dies benennt auch schon den Hauptanwendungsfall: Internet- oder Information-Appliances - in Form von Webpads, Thin-Clients oder Ähnlichem. Geräte, die meist ohne Platte auskommen, einen kleinen Memory-Footprint (Speicherbedarf) aufweisen und Internet-Dienste sowie Standardprotokolle wie PCMCIA, USB oder PCI voll unterstützen sollen. Midori gibt es für x86-kompatible Prozessoren, zu denen auch der Crusoe gehört.

Viele Optionen zur Platzoptimierung

Midori erhebt nicht den Anspruch auf das minimale Embedded Linux, sondern versucht ein ausgewogenes Verhältnis zwischen Haupt- respektive Flashspeicher-Bedarf und Funktionsumfang zu realisieren. Oft verfügen diese Geräte über einen Browser als Hauptapplikation und stellen gehobene Ansprüche an die Hardware; ‘Graphic needs space’ - auf diesen einfachen Nenner lässt sich der Ressourcenhunger der farbigen Geräte bringen - und Linux steht hier, als Zwitter aus Server und Desktop-Rechner im Vergleich zu anderen Embedded Systemen gut da. Dank Kompression um den Faktor 1,5 bis 2 findet ein Standardsystem durchaus auf einem 16-MByte großen Flash-ROM Platz.

Sicherlich lässt sich die Kompressionsrate noch weiter erhöhen, indem man Programme oder Bibliotheken neu kompiliert. Alternative, auf den Internet-Appliance-Einsatz optimierte X11-Varianten wie der OpenSource-Vertreter ‘tinyX’ oder Framebuffer-basierte Fenstersysteme können weitere Ressourcen freisetzen. Midori benutzt zur Platzoptimierung das ‘Multi Call Binary’ busybox. Dieses vereint viele Programme in einem einzigen Binary, auf das die eigentlichen Anwendungen durch symbolische Links verweisen. Durch diese effektive Art des Code-Sharings, ergibt sich im Vergleich zu den Einzelapplikationen eine hohe Platzersparnis. So beinhaltet busybox so gut wie alle Administrationsprogramme, wie ls, mount, tar, ifconfig, route, sed oder reboot. Welche davon im Zielsystem bereitstehen, spezifizieren Einträge im webbasierten Konfigurationsprogramm.

Open Source als Abgrenzungskriterium

Im Vergleich zu anderen Embedded Systemen liegt Midoris großer Vorteil sicher darin, dass Transmeta die Quellen aller Pakete mitliefert und dass das Paketmanagement die Binaries für das Zielsystem erst aus den Sourcen übersetzt - inklusive Compiler und Übersetzungstools. Dies macht zukünftige Portierungen, zum Beispiel auf PowerPC oder Arm, fast zum Kinderspiel - vorausgesetzt, die entsprechenden Cross-Compiler stehen zur Verfügung.

So ist es in Zukunft durchaus denkbar, dass nicht nur der Linux-Kernel als integrale Komponente den Standard vorgibt, sondern ein Basissystem für Embedded-Anwendungen wie Midori. Dann könnten Anwender nicht nur den Kernel oder den X-Server als Grundelement nutzen, sondern eine Basisdistribution - offen und flexibel genug für spezifische Anpassungen.

Mehr Infos

Quellen

ACPI

Linux-Kernel

Midori

Midori Sourceforge

Transmeta

Zusammen mit der Dokumentation und dem Archiv der Mailing-Listen liegt der zirka 160 MByte große Distributions-Brocken auf midori.transmeta.com. Da Transmeta das Paket im Moment nur via HTTP bereitstellt, bietet es sich an, den Download der etwa 60 Einzelpakete per wget -m http://midori.transmeta.com/pub/ zu erledigen. Alternativ besteht über Sourceforge (siehe Kasten ‘Quellen’) ein öffentlicher Zugriff auf einen CVS-Server.

Bibliotheken oft hakelig

Als Entwicklungsplattform empfiehlt sich RedHat 6.x - der Autor hat mit einer Version 6.1 gute Erfahrungen gesammelt. Mit SuSE 7.1 oder dem aktuellen RedHat 7.1 ließ sich Midori nicht erfolgreich nutzen, was sicherlich daran liegt, dass diese eine zu aktuelle glibc-Version einsetzen - die Midori-Webpage verspricht hier in Kürze Anpassungen. Nach einer Minimal-Installation von RedHat 6.1, die lediglich alle benötigten Tools und Bibliotheken aufweist, lässt sich dieses Red-Hat-System mit der darin enthaltenen Midori-Umgebung via chroot wunderbar in modernen Distributionen verwenden. Eine solche Minimal-Installation für die Midori-Umgebung benötigt etwa 100 MByte Plattenplatz - eine leicht zu verschmerzende Größenordnung, zumal man sich damit weitgehend die Unabhängigkeit von einer speziellen Linux-Distribution verschafft.

Allerdings sollte die Entwicklungsmaschine über ausreichend Leistung verfügen. So kann das System einen Dual-P6 mit 700 MHz für den ersten Build-Vorgang fast zwei Stunden beschäftigen - unter 128 MByte RAM sollten ebenfalls nicht im Rechner stecken. Alle temporären Dateien sowie der Cache im Dateisystem-Baum belegen nach einem Build zirka 1,7 GByte, sodass man hier Platzreserven vorhalten sollte. Das Gleiche gilt, falls man zum Experimentieren einen kompletten Entwicklungsbaum einfrieren oder sichern möchte - angesichts heutiger Plattenpreise relativ leicht erfüllbare Forderungen.

Grafische Konfiguration unvollständig

Nach dem Auspacken des Archives midori-1.0.0-beta1.tar.gz, das die Online-Documentation, das Toplevel-Makefile sowie die Verzeichnisse für Konfigurationen und die Applikationen enthält, sind alle Paket-Archive - Dateien mit der Endung mlz - in das Unterverzeichnis apps zu kopieren.

Anschließend steht nach einem make webconfig das webbasierende Konfigurationstool mlconfig des Midori-Build-Systems zur Verfügung. Via Browser definiert man über http://localhost:2000/ sowohl das eigentliche Midori-System als auch das Zielsystem. mlconfig stellt lediglich ein Frontend für die Konfigurationsdatei config dar - kleinere Änderungen lassen sich dort durchaus per Editor realisieren.

Alle Systemparameter für das Ziel- und Midori-Build-System liegen in einer Baumstruktur und verfügen über eine verständliche kontextbezogene Hilfe. Zu beachten ist, dass man Parameteränderungen auf jeden Fall per ‘Accept’-Button bestätigen muss. Bei der diesem Artikel zugrunde liegenden Betaversion musste der Autor in vielen Fällen noch Hand anlegen. So lässt sich für X11 im Konfigurator zwar die gewünschte Bildschirmauflösung einstellen, einen Parameter für den Grafikkarten-Typ sucht man vergeblich. Da XFree86 4.0 alle hardwareabhängigen Treiber in nachladbare Module auslagert, muss das entsprechende Modul Bestandteil der Ziel-Distribution werden. Im Moment geschieht dies nur per Hand in cache/build/X/files. Will man gezielt die X11-Konfiguration beeinflussen und nicht die beispielhafte XF86Config benutzen, so ist diese unter cache/build/X/ abzuändern.

Nach dem Speichern der Einstellungen startet ein make images beziehungsweise make den eigentlichen Build-Vorgang. Da dieser beim ersten Aufruf zunächst eine ganze Reihe von Paketen kompiliert, kann der Vorgang mehrere Stunden Zeit in Anspruch nehmen. So übersetzt Midori im ersten Schritt mit dem systemeigenen Compiler einen eigenen Compiler mit den dazugehörigen Tools. Diesen benutzt es für alle weiteren Build-Vorgänge, um das Zielsystem konsistent zu halten.

In cache/image landen die vom Build-Prozess erzeugen Images root.img.cram (Root-Filesystem/Kernel), config.img.packed (Konfiguration), main.img.packed (Haupt-Partition, mit /usr) sowie mbr.img, (Masterboot-Sektor). Das dazugehörige komplette Filesystem befindet sich in cache/root.

Aufgeteilt ist ein Midori-System in vier Partitionen, zwei Systempartitionen (die je einen Kernel enthalten), eine Daten-Partition für die Konfigurationsdaten sowie die Haupt-Partition, die /usr enthält. Als Dateisystem benutzt Midori cramfs, das die Daten komprimiert ablegt und ‘on-the-fly’ dekomprimiert. cramfs erlaubt nur lesenden Zugriff. Deswegen setzt man es in Kombination mit dem ramfs-Dateisystem ein, um bestimmte Bereiche wie /tmp schreibbar zu realisieren.

Platz sparend gepackt

Transmeta hat cramfs um einige auf den Embedded-Einsatz spezialisierte Funktionen erweitert. So bietet einer der Bootloader die Option, ‘Packed cramfs Images’ anzulegen. Diese fassen mehrere verschiedene cramfs-Dateisysteme zu einem Image zusammen. Bei Midori-Systemen besteht /usr beispielsweise aus einem solchen Packed Image. Damit kann man eigene cramfs-Filesysteme für Applikationen wie Netscape anlegen, die sich bequem in die gepackte /usr-Partionen einbinden lassen. Dies erlaubt das Update spezieller cramfs-Dateisysteme, ohne die komplette /usr-Partionen neu schreiben zu müssen. Darüber hinaus lassen sich Teile gezielt deaktivieren oder löschen.

Nach einem erfolgreichen Build-Vorgang, startet make install den Schreibprozess auf das Blockdevice, make install_zero löscht das Gerät, bevor der eigentliche Schreibvorgang startet. So löst make INSTALL_DEVICE=/dev/sdbinstall_zero den Schreibvorgang auf das zweite SCSI-Blockdevice aus. Wichtig ist, dass der Parameter INSTALL-DEVICE entweder im Makefile oder im Konfigurator auf das richtige Gerät verweist. Ein falsch gesetzter Wert kann trotz chroot-Umgebung das Entwicklungssystem unwiderruflich beschädigen. Der Schreibvorgang beinhaltet die Installation des Bootloaders, das Einrichten der Partitionen sowie das Schreiben der Images, sodass anschließend ein bootfähiges System zur Verfügung steht.

Ähnlich wie zur Konfiguration des Midori-Build-Systems, lässt sich das Zielsystem via HTML konfigurieren. Wie in der Abbildung zu sehen, erreicht man diese über die IP-Adresse des Systems. Nach erfolgreicher, auf Wunsch abschaltbarer Authentifizierung stehen verschiedene Optionen bereit: Setzen von Zeit/Datum und Zeitzone, Netzwerk-Einstellungen, Software-Updates, Reboot, Ausschalten des Systems oder Starten einer Debug-Console.

Sicherlich ist dieser Konfigurator nur als erster Ansatz zu verstehen, da er wichtige Parameter, wie das Startverhalten, die X11-Konfiguration oder Teile des Window-Managers, nicht ändern kann. Hier ist zu erwarten, dass aufgrund des modularen und gut durchdachten Designs schnell weitere Softwaremodule entstehen.

Der eingesetzte Linux-Kernel 2.4.0/2.4.1 weist einige speziell für Embedded Systeme interessante Erweiterungen auf. Hierzu gehören ein ACPI-basiertes Power-Management, Support für die Crusoe-spezifischen Stromspareigenschaften, ein komprimiertes Dateisystem für Flash-Speicher (cramfs), ein dynamisches RAM-Filesystem für Runtime- oder Cache-Daten (ramfs) sowie ein direkt aus dem Flash benutzbares Boot- beziehungsweise Runtime-System.

Ausfallsicherheit groß geschrieben

Midori bietet außerdem einige Eigenschaften zur Erhöhung der Ausfallsicherheit. Durch den Einsatz von via Loopback ins Root-Dateisystem eingebundenen cramfs-Images erhält das System auch bei Unterbrechungen die Konsistenz der Dateisysteme. Alle persistent zu speichernden Konfigurationsparameter befinden sich in einer speziellen Partition (in der 3. Partition) - zur Laufzeit liegen alle Parameter unterhalb des Verzeichnisses /tmp/config. Der Aufruf /sbin/freeze generiert aus diesen Daten ein Image, und speichert dies auf dem Flash. Bei jedem Systemstart restauriert das Kommando /sbin/thaw den Inhalt von /tmp/config aus diesem Image. Eine weitere Besonderheit ist der Bootloader und die Existenz von zwei Systempartitionen beziehungsweise Kerneln. Bei einer beschädigten ersten Systempartition - sei es das Root-Filesystem-Image oder der Kernel - kann der Bootloader die Backup-Kopie starten. Anschließend kann der Systemverwalter die defekte Partition wieder restaurieren. Dieser Mechanismus stellt praktisch sicher, dass das System auf jeden Fall in den Modus startet kann, der Reparaturen oder Updates ermöglicht.

Um die für den Systemstart benötigte Zeit zu minimieren, ist der Boot-Prozess einfach und linear gehalten, - eine für Appliances eine wichtige Eigenschaft. Schön für Systemintegratoren: Alle Debug-Meldungen lassen sich abschalten und die Konsole mit einem beliebigen Boot-Logo versehen. So besteht das init-System im wesentlichen aus zwei Shellskripten /sbin/init und /usr/sbin/init, die die Dateisysteme einhängen, das Netz konfigurieren und schließlich X11 starten. Änderungen am Startvorgang können entweder manuell im Root-Baum (cache/root) oder in den Build-Skripten der entsprechenden Pakete erfolgen.

Zeitgemäß verfügt Midori über die Option, die Images beziehungsweise Partitionen über das Netz zu aktualisieren. Hierzu startet man auf dem Update-Server mit den neue Images ein make upgrade. Auf dem Client lässt sich das Update entweder über die lokale HTML-Oberfläche oder in der Shell starten. Für Letzteres beendet man per ‘<Strg> + <Alt> + <Backspace>’ den X-Server und startet den Update-Prozess durch das Kommando upgrade -h servername:portnummer. Die Portnummer spezifiziert im Midori-Konfigurator der Bereich ‘packcramfsupgrade’, Default ist Port 9999.

Für die Verwaltung der Root- und /usr-Dateisystem verfügt jedes Image über eine so genannte Edition - im Regelfall eine kontinuierlich inkrementierte Zahl. Diese erlaubt beim Erscheinen einer neueren Edition das gezielte Einspielen einzelner cramfs-Dateisysteme, beispielsweise für Netscape, innerhalb der gepackten /usr/-Partition.

Noch ein paar Worte zum eingesetzten - Midori eigenen - Paketformat. Sicherlich existieren unzählige Varianten, Software-Pakete zu verwalten. Transmeta wollte wohl ein einfach strukturiertes Format benutzen, das dennoch den Anforderungen gerecht wird. Dieses basiert auf einem mittels tar archivierten und mit gzip komprimierten Archiv und muss zwingend einige Bedingungen erfüllen:

Die Speicherung der Pakete erfolgt im tgz-Format, sie besitzen die Endung mlz. Jedes Paket entpackt sich in ein eigenes Unterverzeichnis unterhalb von apps. Die Benennung erfolgt als name-n.mlz, wobei ‘n’ für eine Midori-eigene Versionsnummer steht. Ein Skript namens build steuert den Übersetzungsvorgang und kopiert die fertigen Binaries an die richtigen Stellen im Dateisystem. Schließlich definiert die Datei CONFIG die entsprechenden Parameter für den Konfigurator.

Einige Anregungen

Es existiert noch eine Reihe von Verbesserungsvorschlägen: so beschäftigt sich der Autor momentan damit, das cramfs-Filesystem in der Hinsicht zu erweitern, dass es temporäre, nicht persistente Schreibzugriffe (im Buffercache) erlaubt. Dies würde weniger Arbeit für das Systemdesign bedeuten. In der Regel wollen einige Programme ihre Dateien als Cache für Runtime-Informationen oder als Container für Logdaten im Root-Filesystem ablegen (/etc/mtab, /var/run/, /var/log et cetera).

Weiter fehlt eine ausfallbeständige Sicherung der Konfigurationsdateien - bei einem Systemabsturz während eines Schreibvorganges sollten auf jeden Fall die vorherigen Daten noch vorhanden sein oder restauriert werden können. Ein denkbarer Ansatz könnte ein speziell ‘getuntes’ ReiserFS sein, das den Aufwand für das ‘Journaling’ in Bezug auf die geringe Datenmenge in Grenzen hält.

Als sinnvolle Ergänzungen zum Standardsystem könnten zum einen eine chroot-Umgebung (zum Beispiel auf der Basis von RedHat oder Debian) für das Midori-System und eine Quotierung der maximalen Größe von ramfs-Filesystemen gelten. Letzteres soll verhindern, dass das /tmp-Filesystem nahezu beliebig anwachsen kann.

Fazit

Abschließend bleibt zu sagen, dass dieser Artikel sicherlich nur einen kleinen Einblick in das Midori-System geben kann. Viele Prinzipien und Strukturen klären sich erst bei einer intensiveren Beschäftigung mit dem System. Beim Autor hat Midori einen positiven Eindruck hinterlassen. Vor allem der Ansatz, alle Pakete aus den Quellen zu generieren und dies mit einem mächtigen, aber dennoch einfach strukturierten Build-System zu verwalten, ist überzeugend. Das System ist einfach und klar aufgebaut und auf den Anwendungsfall hin entworfen, ohne dabei unflexibel oder schwer erweiterbar zu sein, anders als dies teilweise bei kommerziellen Systemen der Fall ist, die oft eine ‘eierlegende Wollmilchsau’ implementieren. ‘Keep it simple and stupid’ ist doch an einigen Stellen als grundlegendes Prinzip ein richtiger Schritt.

Sicher gibt es im Moment noch Anwendungsfälle, die Midori noch nicht abdeckt - aber dies ist einfach als Herausforderung und Aufruf an die Linux-Gemeinde zu verstehen, hier dem ‘grünen’ Pinguin auf die Sprünge zu helfen.

Björn Dähn
ist als ‘Head of R&D’ der Augsburger Infomatec IAS für den Client-Bereich der CrossTV-Plattform verantwortlich und arbeitet seit über vier Jahren im Bereich Embedded Linux.

Literatur

[1] Björn Dähn; Linux/II; Auf dem Vormarsch; Pinguine in Embedded Systemen; iX 4/01, S. 60 ff.

Mehr Infos

iX-TRACT

• Mit Midori liefert Transmeta ein kostenloses, auf die hauseigenen x86-kompatiblen Crusoe-CPUs angepasstes Werkzeug zur Implementierung von Linux auf Embedded-Geräten.
• Beim Build von Images übersetzt das System alle Applikationen inklusive des Compilers aus den mitgelieferten Quellen für das Zielsystem.
• Durch die Benutzung von Standardkomponenten bleibt das System offen und flexibel.

Daten und Preise
Midori Linux
Anbieter:	Transmeta, www.transmeta.com
Betriebssystem:	Kernel 2.4.x mit cramfs, ramfs, busybox; glibc 2.1.x
Netz:	DHCP, Ethernet, PPP, PPPoE
GUI:	XFree86 4.0.x, Netscape Navigator 4.7x
Sonstiges:	Audio, automatische Updates, MLZ Package Management, MS TrueType Webfonts, USB, PCMCIA, Touchscreen, WLAN
Preis/Lizenz:	kostenlos, GPL

(avr)