Architekturentwurf t Philip Masser Martin Dbler Mathias Rieder Flrian Reischer Christian Gmeiner Christian Hämmerle
Überblick Beispielapplikatin Architekturentwurf Kernel Treiber und Server Btprzess Scheduling Interprzesskmmunikatin Swapping Organisatrischer Rückblick Planung weiterer Schritte
Beispielapplikatin Digitaler Bilderrahmen Anzeigen vn Bitmapbildern auf SD-Karte Abspielen vn Hintergrundsund vn SD-Karte Steuern der Bilderabflge durch Tastendrücke _ Vrwärts _ Rückwärts _ Slideshw
Architekturentwurf
Rechte vn Przessen 3 Privilegienstufen Kernel darf alles Unprivilegierte Przesse eingeschränkte SysCall API kein Zugriff auf Hardware Priviligierte Przesse vlle SysCall API können Privilegien vererben können andere Przesse beenden
Kernel Mikrkernel Kmmunikatin aus beren Schichten via SYSCALLS (static LIB) Mehr Stabilität und Flexibilität in den beren Schichten
HAL Für jede Architektur existiert eine eigene HAL Funktinen für den Kernel Ein- bzw. Ausschalten einer Interruptquelle Hardwaretimer-Interface für Scheduler Fault-Handler für unkntrllierte Exceptins Funktinen für die Treiber Registrierung auf Hardware-Interrupts IO-Zugriff direkt auf Register Autmatisches PIO Setup für LEDs und Taster Infrmatin über Devices und deren Ressurcen Schnittstelle für DMA
Treiber und Server Treiber und Server meist ein Przess Kmmunikatin mit Servern mittels SERVICE CALLS Treiber kmmunizieren mit Kernel mittels SYSCALLS Möglichst kmfrtable API für den Prgrammierer (static LIB)
Sund Server und Treiber Treiber und Server sind ein Przess Schnittstelle zum Sund-Chip und dem Audiausgang Kein Buffering und Prefetching LOAD(FILENAME) PLAY() PAUSE() STOP() SETVOLUME(LEVEL)
Btprzess 1. startup_init (Generelles Hardware-Setup) 2. int main des Kernels 1. HAL initialisieren 2. InterruptHandler / Clck / Scheduler starten 3. IPC und Memry Management initialisieren 4. InitPrcess starten 1. Treiber/Server starten 2. Eingebaute Prgramme starten (Shell )
Scheduling Anfrderungen an den Scheduler Minimale Latenzzeit (Antwrt bzw Jbfertigstellungszeit) Maximaler Jbdurchsatz Maximaler Ausnutzungsgrad (I/O-Geräte müssen maximal ausgenutzt werden) Fairness (Jeder Jb bekmmt Ausführungszeit, keiner verhungert)
Scheduling Verfahren in Anlehnung an Rund Rbin Viele Przesse in RUNNABLE Status Welcher Przess wird ausgeführt, wenn Priritäten ität benutzt t werden? 0 RUNNABLE Przesse: Starvatin (Abhilfe durch IDLE Przess) 1 RUNNABLE Przess: Einfach > 1 RUNNABLE Przesse:? Runnable Running Dead Dead Blcked Zmbie
Scheduling Präemptives Rund Rbin mit mehreren Queues für Priritäten Clck gibt Ticks über Interrupt Quantum muss festgelegt t werden Tradeff: Respnsiveness vs. Scheduler Rechenzeit Tannenbaum empfiehlt 100ms HIGH-Pririty P P P P P P P P P P P... 7 /10 2 /10 P P P P P P P P P P P LOW-Pririty P P P P P P P P P P P 1 /10
Scheduling Speicherbedarf abhängig vn Maximaler Anzahl Przesse Anzahl Queues Bei max. 256 Przessen und drei Queues 23.5 KB (24098 Bytes) Bei max. 64 Przessen und drei Queues 6 KB (6050 Bytes)
Scheduling Aufwände für Operatinen Anlegen eines neuen Przesses Maximal O(Anzahl Przesse) Mininmal Ω(1) In der Regel: O(Anzahl Przesse / 2) Rescheduling O(Anzahl der Przesse) Jedch Zugriff auf Przesse, Przessswitches etc O(1)
Scheduling Prblem? Abhilfen Respnse Rati berechnen Gewichtung der Priritäten nach Anzahl Przesse in der Queue
Scheduling und Echtzeit Verfahren für harte Echtzeit scheinen nur wenig relevant Rate Mntnic Scheduling Deadline Mntnic Scheduling ptimiert für peridische Przesse (Peridendauer = Deadline) Lösung: RundRbin welches die Ideen vn Highest Respnse Rati Next verwendet
Highest Respnse Rati Next Prirität wächst prprtinal zur Respnse Rati rr = rt + wt rt = Laufzeit + Wartezeit Laufzeit 6 5 4 3 running 2 rr= 1 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 t
Interprzesskmmunikatin Grundsatzentscheidung: Shared Memry der nicht? Shared Memry ist schnell aber gefährlich Micrkernel sll Stabilität bringen, deshalb wllen wir auch ein stabiles IPC Lösung: Named Pipes
Simples IPC SundServer.SetVlume
Simples IPC SundServer.SetVlume
Simples IPC SundServer.SetVlume Nachteil des simplen IPC sind die zahlreichen Syscalls Wie können wir Syscalls einsparen und die Kmmunikatin zwischen den Przessen beschleunigen?
IPC mit Pipes SundServer.SetVlume
IPC mit Pipes SundServer.SetVlume
Pipe Datenstruktur Durch geschickte Wahl der Datenstruktur einer Pipe kann auf ein Synchrnisiertes Lesen verzichtet werden: read-pinter write-pinter read-pinter erst NACH Leseperatin erhöhen. LA A0 A2 A3... Przess kann unterbrchen werden, kein Überschreiben Länge der Message A Message A : : Ring-Array - Overhead durch Länge der Message + Synchrnisieren beim Lesen fällt weg B2 B3... 4 B0 B1
Interrupt Handling Hardware-Interrupts werden vm Kernel verwaltet Treiber können sich auf Interrupt request-# registrieren Tritt Interrupt auf, wird dieser vm Kernel über IPC an den jeweiligen Treiber geschickt Kernel quittiert Interrupt Ausnahme: Interrupts für Clck-Treiber für Scheduler Interrupt wird in der HAL abgehandelt und eine Callback Methde im Kernel aufgerufen.
Interrupt Handling
Swapping Prblem: Wer übernimmt Swapping/Paging in einem Micrkernel Kernel Wann (Page fault) Wie (Strategie: z.b.: Least Recently Used) SD-Treiber Physikalisches Schreiben und Lesen der Pages Darf nicht ausgelagert werden Kmmunikatin über IPC Auszulagernde Page (SD-Queue) Zu ladende Page (SD-Queue) Kernel (Scheduler) übergibt dem SD-Treiber die CPU
Organisatrischer Rückblick Wöchentliche Dienstagsmeetings Review der Ergebnisse aus letzter Wche Besprechung der Wiki-Artikel Prblembereiche identifizieren Detailresearch Diskussin in der Gruppe Neue Aufgabenverteilung gfür die kmmende Wche Research und Lösen der Aufgaben in Heimarbeit (ggf. in Partnerarbeit falls Themen und Aufgaben verwandt sind)
Organisatrischer Rückblick Archivierung der Artikel und Ergebnisse mittels Wiki im PM-System www.assembla.cm Histrisierung der Artikel Tickets, Tasks, Messaging Service Zeiterfassung Subversin für Surce Cde und Präsentatinen, Grafiken Autmatische Email-Generierung an alle/bestimmte Mitglieder
Planung weiterer Schritte Timebx 2 (bis 9.12.) 12) Implementierung des Betriebssystemkerns Vllständiger Kernel, RS232 Server und Shell Geschätzter t Implementierungsaufwand 201 Stunden Timebx 3 (bis 20.01.) Implementierung der Treiber und Server, Beispielapplikatin und erweiterte Funktinalitäten (DMA, Swapping ) Geschätzter Implementierungsaufwand 225 Stunden