Mi 6.3 January 22 th -26 th, 2007, Munich/Germany Migration zu Embedded Linux Christoph Stückjürgen Organized by: Lindlaustr. 2c, 53842 Troisdorf, Tel.: +49 (0)2241 2341-100, Fax.: +49 (0)2241 2341-199 www.oopconference.com
Corporate Technology Migration zu Linux Christoph Stückjürgen, Siemens AG CT SE 2 Copyright Siemens AG 2006. All rights reserved. Overview 1. Einführung und Motivation 2. QNX Linux 3. VxWorks Linux 4. Proprietär Linux 5. Zusammenfassung 2 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
1. Einführung und Motivation 3 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Corporate Competence Center Embedded Linux und Embedded Linux Initiative - Ursprung Eine vom Zentralvorstand beauftragte Studie lieferte Antworten zur Frage Sollte Siemens seine Software- Strategie ändern? Hauptaugenmerk der Studie war zu untersuchen, ob Siemens in ein Embedded Betriebssystem investieren sollte...um die Anzahl verwendeter Betriebssysteme zu verringern und so zu strategischen Vorteilen zu kommen Eine gemeinsame Siemens Betriebssystem Plattform Strategie hätte folgende Vorteile: Kürzere Time-to-market Kostenreduktion Einfachere Wiederverwendung von Softwarekomponenten 4 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
Ergebnisse und Konsequenzen der Studie: Embedded Linux Bei Siemens werden viele verschiedene Embedded Betriebssysteme eingesetzt. Die Ausgaben für Embedded Betriebssysteme (Lizenzen, Support) werden auf 20-40 Millionen pro Jahr geschätzt. Ein einheitliches Embedded Betriebssystem hätte signifikante strategische und finanzielle Vorteile für Siemens Siemens sollte nicht versuchen, ein einziges kommerzielles Betriebssystem für alle (oder die meisten) Anwendungsbereiche einzuführen. Das einzige Betriebssystem, welches Potenzial für eine solche Vereinheitlichung hat, ist Embedded Linux. Siemens sollte den Einsatz von Embedded Linux unterstützen 5 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Embedded Linux Mission und Legitimation Das einzige Betriebssystem, welches Potential für eine solche Vereinheitlichung bietet, ist Embeddded Linux. Präsentation der Ergebnisse Zentralvorstand AIT Entscheidung Embedded Linux soll innerhalb von Siemens als bevorzugte Betriebssystemplattform für Neuentwicklungen eingeführt werden. Realisierung Corporate Competence Center Embedded Linux wird aufgesetzt Ziel: Siemens Geschäftsbereiche in die Lage versetzen, die Vorteile von Linux bei geringem Risiko zu nutzen. 6 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
Motivation Linux bevorzugtes Embedded Betriebssystem innerhalb von Siemens. Software für bestehende Systeme wurde für andere Betriebssysteme geschrieben. Bestehende Software soll wiederverwendet werden. Entwicklung von effizienten und effektiven Migrationsstrategien 7 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology 2. QNX Linux 8 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
QNX und Linux QNX Microkernel Gerätetreiber als Prozesse POSIX API für Gerätetreiber POSIX API für Prozesse IPC: POSIX, channels Echtzeit-Betriebssystem Linux Monolithischer Kernel Gerätetreiber Teil des Kernel Kernel API für Gerätetreiber, nur C, nicht standardkonform POSIX API für Prozesse IPC: POSIX, System V Echtzeitfähigkeit nur über Erweiterungen (RTLinux, RTAI) 9 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology QNX und Linux: Microkernel und monolithischer Kernel 10 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
Interprozess Kommunikation QNX Linux Neben POSIX Mechanismen auch proprietäres Message-Passing im Mikro-Kernel implementiert (Channels, Pulses) Grundlage für sämtliche Kommunikation zwischen Kernelund User-Space Synchrones Messaging: Send Receive Reply Semantik libqmsg Projekt (http://libqmsg.sourceforge.net/) Bildet Semantik des QNX Messaging durch POSIX Message Queues und Shared memory nach Wurde vom Corporate Competence Center Embedded Linux der Siemens AG entwickelt Liberale Lizenz: MPL (Mozilla Public License) problemlose Integration in eigene Projekte 11 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology libqmsg Durchsatz Lastszenarien: 1 unbelastet 2 ein Prozess 3 mehrere Prozesse 4 Interrupt 5 Interrupt und ein Prozess 6 Interrupt und mehrere Prozesse 12 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
libqmsg Latenz Lastszenarien: 1 unbelastet 2 ein Prozess 3 mehrere Prozesse 4 Interrupt 5 Interrupt und ein Prozess 6 Interrupt und mehrere Prozesse 13 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Migration von QNX Gerätetreibern Linux Kernel API entspricht keinem Standard Mögliche Strategie: Verlagerung von Treiberfunktionalität in den Linux User-Mode (POSIX API) Wiederverwendung von Standard Open Source Treibern Verwendung von FUSE zur Kommunikation zwischen Applikation und Treiber 14 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
Beispiel: Migration eines QNX CAN Treibers QNX Linux Application CAN driver Device file /dev/candrv Application /dev/candrv FUSE kernel module CAN driver high level handling and glue /dev/can0 lincan Open Source CAN driver User Mode Kernel Mode QNX: CAN Treiber kommuniziert mit Applikation über Spezialfile /dev/candrv Linux: Verwendung von FUSE zur Einblendung von /dev/candrv Verwendung des existierenden Linux CAN Treibers lincan für Low- Level Funktionalität User-Mode Treiberanteil für Schnittstellenwandlung und High-Level Handling 15 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Kochbuch für die Migration von QNX Systemen nach Linux Identifiziere Hardware Zugriffe und Interrupt Handling Isoliere diese Komponenten ( Treiber ) vom Rest des Systems ( Applikationen ). Verwende existierende Linux Treiber falls verfügbar oder implementiere die QNX Treiber neu unter Linux. Verwende libqmsg für QNX-spezifische IPC (channels, pulses). Verwende einfache Wrapper-Funktionen, um Applikationen zu migrieren. Migration von Applikationen meist einfach (POSIX). Aufwand für Migration von Treibern kann durch Wiederverwendung bestehender Open Source Treiber minimiert werden. 16 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
3. VxWorks Linux 17 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology VxWorks und Linux Kernel Scheduling IPC VxWorks Microkernel Funktionalität: Scheduling IPC Interrupt Handling Watchdog Timer Memory Management Preemptive priority (FIFO) Round-Robin POSIX, System V Linux Monolithisch FIFO Round-Robin Standard time-sharing POSIX Memory management Interrupt Handling Gerätetreiber Kein Speicherschutz (vor Version 6.x) Speicherschutz, Virtueller Speicher, eigener Adressraum für jeden Prozess Verbindung von Applikationscode zu Im Kernel einer Interrupt Service Routine möglich POSIX API, Wind Kernel API Linux Kernel API 18 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
Migration von VxWorks Software APIs für Applikationssoftware ähnlich POSIX Einfache Wrapper für die meisten VxWorks spezifischen API Funktionen Kernel API für Gerätetreiber ähnlich Drei Klassen von Gerätetreibern Netzwerktreiber Blocktreiber Zeichentreiber Ähnliche Semantik Hauptproblem meist: Applikationen nutzen lineares Speichermodell für IPC. 19 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Abbildung von VxWorks Tasks auf Linux Threads/Prozesse Nullte Näherung : 1:1 Abbildung von VxWorks Tasks auf Linux Threads in einem Prozess Adressraum des Prozesses entspricht linearem Adressraum von VxWorks Problem: Eingeschränkte Debugging Möglichkeiten von multithreaded Applikationen unter Linux Richtlinien für sinnvolle Abbildung von VxWorksTasks auf Thread/Prozesse: Erzeuge bei Initialisierung, Threads u.u. auch dynamisch Verwende Prozesse, um 3rd Party Code abzuschotten Prozesserzeugung: Typischerweise 10-100ms. Threaderzeugung: Typischerweise einige 10 ms. 20 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
legacy2linux, v2linux Linux Bibliotheken zur Emulation der VxWorks API Abbildung Tasks Threads Nur für Applikationen Geeignet für Rapid Prototyping Erfahrung aus Projekten: Probleme mit Bugs in der Bibliothek, Probleme mit massivem Thread-Einsatz 21 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Vorteile einer VxWorks nach Linux Migration aus einem Projekt aus dem Bereich Telekommunikation Schnellere Fehleranalyse wegen Prozessmodell und einer reichen Vielfalt an Monitoring Tools (z.b. top, strace, ltrace, ltt, /proc, core dumps...) Beschleunigung der Applikationstests wegen ähnlicher Umgebung auf Host und Target (Regressions Suite vor Migration: 17 Stunden auf einem Target, jetzt 2 Stunden auf 5 Linux PCs) Schneller und hochwertiger Support aus der Linux Community: Workaround für PPC405 CPU Bug für Linux verfügbar, nicht aber für VxWorks. Support für Nachfolgeprozessor PPC 440 GX im Linux Kernel. Systemverbesserungen durch bestehende Linux Komponenten (e.g. vsftp, nfs server, syslog-ng, reiserfs). Security Anforderungen können meist schnell und einfach erfüllt werden (ssh, Firewall, Benutzerrechte, etc.). Verwendung aktueller gcc Compiler möglich. 22 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
4. Proprietär Linux 23 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Migration von proprietären Systemen Häufig verwendete Strategie: Proprietäres OS wird auf Linux portiert und das gesamte System läuft als ein Prozess unter Linux. Hardware-Zugriffe müssen separiert werden Proprietäres OS als Linux-Prozess Task 1 Task 2 Task 3 Linux Kernel Hardware-Zugriffe durch Linux Treiber Konkretes Projektbeispiel: Brandmeldezentrale 24 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
Brandmeldesystem Vernetztes System Zentrale Baumstruktur mit Brandmeldezentrale als Kopf oder Ringstruktur Kommunikation mittels seriellem Protokoll Kommunikation zwischen Komponenten immer über Zentrale Wird seit 20 Jahren verkauft Bedienfeld Melder 25 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Motivation Brandmeldezentrale basiert auf 8088 Prozessor Programmiersprachen PL/M und Assembler Selbst entwickeltes Betriebssystem Performance-Probleme bei Systemen im Feld Rechenleistung des 8088 Schnittstellengeschwindigkeit der seriellen Kommunikation Neues System basierend auf Pentium Prozessor (später Entscheidung für ARM Prozessor) Linux Betriebssystem Zwei mögliche Migrationsszenarien: Emulation und Konvertierung 26 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
Migration der Brandmeldezentrale: Szenario Emulation Mit 386'er führte Intel speziellen Kompatibilitätsmodus ein Ausführung von 8088 Binaries in diesem Kompatibilitätsmodus möglich Kompatibilitätsmodus wird durch Interrupt oder Exception verlassen dosemu: Nutzt Kompatibilitätsmodus, um eine für DOS geeignete Emulationsumgebung bereitzustellen Verwendung von dosemu als Basis für die Emulation von SM88 User Mode Kernel Mode shared memory Treibersteuerung Linux Kernel Peripheriesteuerung dosemu (angepasst) SM88 shared memory 27 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Migration der Brandmeldezentrale: Szenario Konvertierung Verwendung eines Open-Source PL/M nach C Konverters Anpassungen für erfolgreiche Kompilation und Binden Vorverarbeitung des PL/M Code (Skripte und manuell) Nachbearbeitung des C-Code (Skripte und manuell) Portierung des C-Code PL/M (8088) C (Pentium, Linux) 16 Bit 32 Bit Pointer-Arithmetik mit Segment und Offset Lineare Pointer-Arithmetik Direkte Hardware-Zugriffe Hardware-Zugriffe über Treiberschnittstelle Pointer nicht typsicher Typsichere Pointer 28 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
5. Zusammenfassung 29 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology Zusammenfassung Migration von QNX und VxWorks Applikationen nach Linux wegen gemeinsamer POSIX API großteils einfach möglich Sehr gute Migrierbarkeit bei Verwendung einer Middleware, z.b. ACE/TAO Migration von Gerätetreibern erfordert Handarbeit und oft architekturelle Änderungen Beispiel PL/M Linux zeigt, dass auch von Linux sehr weit entfernte Applikationen migriert werden können, ohne das System komplett neu zu entwickeln 30 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology
Linux Vor- und Nachteile Nachteile: Qualität frei verfügbarer Debugging Tools eingeschränkt Qualität der frei verfügbaren IDE Eclipse+CDT eingeschränkt Vorteile: Enorme Zahl an Features und verfügbaren Komponenten Viele Entwicklungs- und Debugging-Tools Linux entwickelt sich mehr und mehr zu einer Standardplattform im Embedded-Bereich Kein Vendor Lock-in Quellcode verfügbar und modifizierbar 31 21.11.2006 Christoph Stückjürgen, CT SE 2 Siemens AG, Corporate Technology