Kernel- und Treiberprogrammierung mit dem Kernel 2.6 -
Folge 39
Kern-Technik
von Eva-Katharina Kunst, Jürgen Quade
Erschienen im Linux-Magazin
2008/05
RAM- und Temp-Filesysteme sparen Code, Hauptspeicher und Rechenzeit. Beste Voraussetzungen, um damit Linux beim Booten auf die Sprünge zu helfen.
Einen richtigen Namen hat die Technik nicht. Von Early Userland und RAM-Filesystem sprechen die Entwickler. Der eigentlich unkorrekte Begriff Ramdisk beschreibt aber am besten, wie sie funktioniert: Der Computer legt Dateien im Hauptspeicher ab, ist so unabhängig von einer Festplatte und hat schnellen Zugriff auf sie. Gerade Entwickler von eingebetteten Systemen setzen schon lange auf Ramdisks, da sie helfen - genügend RAM vorausgesetzt - die Zahl der Zugriffe auf empfindliche Flashspeicher zu verringern, die nur eine begrenzte Anzahl Schreiboperationen erlauben. Für den Nutzer beinahe unbemerkt bootet heute kein aktuelles Linux-System mehr ohne RAM-Filesystem [1].
Ein in viele Module aufgeteiltes Linux unterliegt einem Henne-Ei-Problem, das erst das Early Userland löst: Treiber und Gerätedateien wie »/dev/console« liegen auf dem Hintergrundspeicher, der Kern benötigt die Treiber jedoch, um auf das Dateisystem zuzugreifen. Mindestens zwei Module sind nötig: Ein Treiber für den Hintergrundspeicher und eines, um das Dateisystem zu interpretieren, beispielsweise »sata« und »ext3«. Dieses Dilemma löst Linux via Virtual File System (VFS) und RAM-FS.
Ohne Treiber
Der Trick ist simpel: Ein Filesystemtreiber ist im Grunde eine Software, die spezifische Eigenschaften der einzelnen Dateisysteme auf das intern verwendete Virtual-Filesystem abbildet und damit dem Kernel ein einheitliches Bild vermittelt. Erst so kann Linux unterschiedliche Dateisysteme homogen als gemeinsamen Dateibaum darstellen.
Die dem VFS zugrunde liegenden Strukturen vermag der Kernel aber auch direkt aufzubauen. Dieser Überlegung folgend erlaubt es das Kernel-Buildsystem, später notwendige Treiber, Gerätedateien und Bootprogramme in ein CPIO-Archiv zu packen und es quasi huckepack an das Kernelimage zu kleben. So schaufelt der Bootloader beides in den Hauptspeicher. Da er und nicht der Kernel diese Arbeit durchführt, benötigt der Datentransport den Kernel gar nicht.
Sobald der Bootloader die Kontrolle an den Kernel überträgt, initialisiert dieser das Prozess- und Memory-Management und konstruiert aus dem im Hauptspeicher befindlichen Archiv das für den Betrieb notwendige Root-Filesystem (Abbildung 1, rechts). Dieser Weg ist viel eleganter, als einen Umweg über eine Ramdisk zu nehmen, bei der der Kernel Hauptspeicher einer bestimmten Größe reserviert, darin ein Filesystem erzeugt und in dieses schließlich Daten aus einem Archiv kopiert (Abbildung 1, links). Dass er stattdessen die Dateien direkt in die Kernel-internen Datenstrukturen des VFS umsetzt, spart Code, Speicherplatz und Rechenzeit.
|
Abbildung 1: Das Early Userland (rechts) entnimmt die Daten seines Root-Filesystems einem komprimierten CPIO-Archiv. Den Speicher, den das Archiv belegt, gibt der Kernel wieder frei, sobald er sich vollständig initialisiert hat. Links ist im Vergleich ein herkömmlicher Filesystem-Zugriff auf die Ramdisk zu sehen.
|
Anders als eine Ramdisk, die immer eine feste Größe von 4, 8 oder 16 MByte hat, benötigt das RAM-Filesystem genau so viel Speicher wie die darin abgelegten Daten. Für eine Datei mit beispielsweise 12 KByte verwendet das Filesystem auch nur 12 KByte RAM. Legt der Anwender mehr Dateien an, wächst das RAM-Filesystem entsprechend mit. Sollten jedoch Amok laufende oder böswillige Threads ein solches Filesystem mit Daten fluten, kann das auch ein Nachteil sein.
Frühes Userland
Desktop- und Server-Linuxe nutzen das Early Userland, um dort Treiber für Festplatten- und Netzwerk-Controller und eventuell zugehörige Firmware abzulegen. Außerdem befindet sich dort ein Programm oder ein Shellskript mit dem Namen »init«, das der Kernel als ersten Prozess mit der PID 1 startet, wenn er das System hochfährt.
Dieses Gespann ermöglicht, zum Beispiel in einem festplattenlosen System, die Root-Partition über NFS per WLAN zu mounten. Der Init-Prozess lädt aus dem RAM-FS eventuell notwendige Firmware, den NFS- und den WLAN-Treiber. Damit ausgerüstet mountet er das neue Root-Filesystem mit Hilfe des Systemcalls »pivot_root«. Das kann durchaus auch wieder ein RAM-Filesystem sein (siehe Kasten "Schlanke Root-Filesysteme"). Jetzt darf er das RAM-Filesystem wieder aushängen und sich selbst per »excec()« in den neuen Init-Prozess verwandeln, dessen Programm auf dem neuen Root-Filesystem liegt (Abbildung 2). Das als Sprungbrett verwendete RAM-Filesystem ist für den Nutzer fortan unsichtbar.
|
Root-Filesysteme, die der Kernel im Hauptspeicher instanziiert und die dort auch bleiben sollen, enthalten typischerweise nicht mehr Funktionalität als unbedingt notwendig. Schließlich steht jedes Byte, das das Root-Filesystem belegt, den Applikationen nicht mehr zur Verfügung. Wann immer es eine Auswahl gibt (etwa »ash« oder »bash«), empfiehlt sich die einfachere und schlankere Variante.
Abgelegte Software lässt sich noch entrümpeln, denn oft braucht ein initiales Root-Filesystem nicht alle Funktionen. Besonders hoch ist das Einsparpotenzial bei Bibliotheken, vor allem der Standard-C-Bibliothek. Da Shared Librarys mit dem notwendigen Framework viel Speicher belegen, setzen einige Entwickler - back to the roots - auf statisch gelinkte Applikationen (siehe Abbildung 5).
Da hierfür die »glibc« zu aufgebläht ist, haben die Kernelhacker eigene handliche Varianten entwickelt, die die wesentlichen Systemfunktionen beinhalten: Die »klibc« [4], »dietlibc« [5] und »newlib« [6] erfüllen auch ihren Zweck. Gerade Entwickler von Distributionen packen zusätzlich die notwendigsten Applikationen in ein Multi-Call-Binary wie beispielsweise »busybox«. Diese Applikation erledigt je nach dem Namen, mit dem sie der Anwender aufruft, unterschiedliche Aufgaben.
Der Kernel übergibt jeder Anwendung ihren Aufrufnamen (zum Beispiel aus der Shell) als ersten Parameter »argv[0]«. Dank Links haben manche Programme viele Namen und der Entwickler muss die Standardbibliothek nur einmal statisch an den Code binden. Mehr dazu erläutert ein eigener Artikel in diesem Heft.
|
|
Abbildung 2: Desktop und Server nutzen das Early Userland als Zwischenstufe, bevor sie das eigentliche Init-System aktivieren.
|
| Whitepaper |
|---|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele
Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
|
The Role of Open Source in Data Integration
Obwohl in den letzten Jahren viele technische Fortschritte erzielt werden konnten, verfügen die meisten Datenintegrationsprozesse nach wie vor nur über eine sehr begrenzte Automatisierung. Das vorliegende White Paper von dem Industry Analyst Mark Madson wird zunächst ein grundlegendes Verständnis von Daten Integration vermitteln, die Vorzüge von Open Source Lösungen für Daten Integration erläutern und Ihnen professionelle Empfehlungen geben, damit Sie Ihre Integrationsjobs noch einfacher und produktiver gestalten können.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
