Flickenteppich

Geschrieben von MMind am Dienstag, 3. Januar 2012 in Software

Eine kleine Bastelei der letzten Tage ist eine Patchtracker-Webanwendung. Diese dient dazu, den Status von Patches auf dem Weg in den Linux-Kernel zu visualisieren.

Die Patchsets selbst liegen dabei einfach in einer Verzeichnisstruktur, die durch die Anwendung ausgewertet wird. Auch die einzufügenden Beschreibungstexte werden durch Dateien in dieser Struktur verwaltet.

Da sich der »Workflow« zum Einpflegen von Patches von Projekt zu Projekt unterscheidet, kann der Tracker durch diesen flexiblen Aufbau an die meisten Projekte angepasst werden.

Besonders »stolz« bin ich dabei auf eine PHP-Klasse zum Parsen von Patch-Dateien, denn bei meinen Recherchen im Vorfeld habe ich nichts derartiges im PHP-Bereich finden können und mich deswegen bei dem im Kernel-Umfeld gern genutzten Python-basierten Patchwork bedient.

0 Kommentare Mehr...

Debian-Pakete auf schwachen Architekturen bauen

Geschrieben von MMind am Samstag, 29. Januar 2011 in Software

Debian-Pakete sollen vor dem hochladen in das Archiv ein einer »sauberen« Umgebung gebaut werden. Im Allgemeinen ist dies ein chroot das durch pbuilder verwaltet wird. pbuilder installiert dabei Pakete, die zum bauen nötig sind in das chroot und räumt sie danach auch wieder weg. Durch die Verwendung von pbuilder, oder einem seiner Verwandten, wird sichergestellt dass alle »build-dependencies« im Paket deklariert sind und dass das Programm nicht gegen irgendwelche obskuren Bibliotheksversionen gelinkt wird, die sich gerade auf dem Host-System befinden.

Schwachen System

Ganz offensichtlich führt schon die geringere Rechenleistung zu sehr langen Kompilationszeiten, sofern nicht vorher der meist ebenfalls geringe Arbeitsspeicher die Kompilation abbricht.

Ein weiteres Problem bereitet der Flash-Speicher, der meist in Embedded-Systemen verwendet wird. Der pbuilder packt für jeden build-Vorgang sein chroot aus, installiert weitere Pakete dort hinein, kompiliert das Programm und räumt schließlich alles wieder weg. Dadurch erzeugt er eine Unmenge Schreibvorgänge, die den Flash-Speichern sehr zusetzen.

Qemubuilder

Qemubuilder startet eine virtuelle Maschine der Zielarchitektur und führt den pbuilder in dieser aus. Das Problem ist nur, dass dies im Allgemeinen noch langsamer vonstatten geht als das direkte Bauen auf dem Gerät.

qemu-user

Via Jabber kam noch der Einwurf, man könnte auch qemu selbst verwenden. qemu-user ermöglicht es, einzelne Programme als andere Architektur auszuführen. Man müsste also ein armel-chroot erstellen, dort hineinwechseln und könnte dann den armel-pbuilder aufrufen. Die entsprechenden qemu-Binaries kümmern sich dann um das Ummodeln der armel-Instruktion in welche für x86. Hab ich heute also wieder was gelernt :-) .

Meine Lösung

Ich habe mich dann einfach dafür entschieden meiner Sammlung von ARM-Geräten eines hinzuzufügen, dass Pakete in einer annehmbaren Geschwindigkeit bauen kann — eben der Toshiba AC100.

Eigentlich dachte ich vorher eher an einen SheevaPlug, den Ausschlag für den AC100 gab dann aber der Umstand dass er das tollere Spielzeug ist und weitere Nutzungsmöglichkeiten ausser dem buildhost-Dasein bietet.

Da er auch einen USB-Host-Port besitzt kann ich auch das Flash-Abnutzungproblem vermeiden indem ich einfach eine USB-Festplatte als Medium für den pbuilder nutze.

0 Kommentare Mehr...

freesmartphone.org - middleware for embedded devices

Geschrieben von MMind am Sonntag, 19. Dezember 2010 in Software

Ein Nebenprodukt der Entwicklung der Openmoko-Platform war das Projekt freesmartphone.org . Dieses hat sich zum Ziel gesetzt eine sogenannte Middleware für mobile Geräte zu entwicklen.

Auch nach dem Ende der Openmoko Telefonproduktion besteht freesmartphone.org fort und bietet momentan Unterstützung nicht nur für Openmoko-Telefone sondern unter anderem auch für den Palm Pre und das Nokia N900.

Middleware bezeichnet Software die zwischen den rohen Treibern des Kernels und Anwendungsprogrammen sitzt und den Zugriff auf die Hardwarekomponenten abstrahiert. So sollte sich zum Beispiel idealerweise eine Telefonie-Anwendung nicht dafür interessieren müssen was für ein GSM-Modem die eigentliche Arbeit tut.

Das ofono-Projekt tut ähnliches aber eben nur auf dem Gebiet der GSM-Kommunikation. freesmartphone.org geht hier aber noch einen Schritt weiter und möchte alle Features eines mobilen Gerätes kapseln.

Die Kommunikation der Komponenten untereinander und mit den Anwendungsprogrammen erfolgt dabei über DBus.

Einzelkomponenten

Der Software-Stack besteht dabei aus mehreren Einzelkomponenten die sich um die verschiedenen Themenbereiche kümmern. Die bisher am weitesten fortgeschrittenen Komponenten sind dabei:

fsousaged - Resourcenmanagement

Der fsousaged kümmert sich um die Verwaltung der Resourcen. In einem mobilen Gerät ist der Stromverbrauch sehr wichtig. Deswegen sollten Komponenten nur aktiviert sein wenn sie auch benötigt werden.

Hier fordern also die Anwendungen den Zugriff auf eine Resource des Gerätes an und der usage-Daemon kümmert sich darum dass das Gerät aktiviert wird. Wenn die letzte Anwendung ihren Zugriff auf die Resource wieder freigibt deaktiviert fsusaged dieses auch wieder.

Ein weiterer wichtiger Aspekt des usage-Daemons ist das sogenannte "suspend-handling". Bei mobilen Geräten ist der Schlaf-Modus (suspend) sehr wichtig um die Akku-Laufzeit annehmbar zu halten. Der Akku würde zum Beispiel schnell schlapp machen wenn das Gerät normal läuft, obwohl es in einer Tasche steckt und höchstens auf einen Anruf wartet. Der fsousaged kümmert sich dabei auch um das Ermitteln des Aufwachgrundes. Dies kann zum Beispiel ein druck auf den Anschaltknopf sein, aber auch ein ankommender Anruf.

fsodeviced - Gerätemanagement

Hier erfolgt die eigentliche Kapselung der Einzelkomponenten der Geräte. D.h. die verschiedenen Eigenarten einzelner Geräte werden ausgeglichen und das ganze dann per DBus-API verfügbar gemacht.

Hier sitzen dann auch Funktionen um manche Geräte das Schlafengehen zu erleichtern. Vor allem GSM-Modems, benötigen viel Hilfe um schlafen zu gehen und trotzdem empfangsbereit zu bleiben und das Gerät bei einem Anruf aufzuwecken.

fsogsmd - Management von GSM-Verbindungen

Der GSM-Daemon kuemmert sich darum Sprach und Datenverbindungen ueber ein GSM-Modem zu ermöglichen. Hier gibt es dann Module die die Eigenarten der verschiedenen GSM-Module überdecken und vor den Telefonieanwendungen verstecken.

GSM-Modems arbeiten zwar im Allgemeinen mit normalen AT-Befehlen, es scheint aber so, dass Hersteller oft eigene Erweiterungen entwicklen oder die Modems manche Befehle nicht korrekt unterstützen.

fsodtld - Zeit- und Ortsverwaltung

Der date-time-location-Daemon kümmert sich um die Bestimmung von Orts- und Zeitwerten. Er nutzt dabei GPS-Empfänger und verschiedene Zeitresourcen zur Bestimmung der Werte.

0 Kommentare Mehr...

Seite 1 von 1, insgesamt 3 Einträge

Suche

Nach Einträgen suchen in Outside the Walled Garden:

Das Gesuchte nicht gefunden? Gib einen Kommentar in einem Eintrag ab oder nimm per E-Mail Kontakt auf!