1 / 31

Philip Masser Martin Dobler Mathias Rieder Florian Reischer Christian Gmeiner Christian Hämmerle

Architekturentwurf. Philip Masser Martin Dobler Mathias Rieder Florian Reischer Christian Gmeiner Christian Hämmerle. Überblick. Beispielapplikation Architekturentwurf Kernel Treiber und Server Bootprozess Scheduling Interprozesskommunikation Swapping

adora
Download Presentation

Philip Masser Martin Dobler Mathias Rieder Florian Reischer Christian Gmeiner Christian Hämmerle

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architekturentwurf Philip Masser Martin Dobler Mathias Rieder Florian Reischer Christian Gmeiner Christian Hämmerle

  2. Überblick • Beispielapplikation • Architekturentwurf • Kernel • Treiber und Server • Bootprozess • Scheduling • Interprozesskommunikation • Swapping • Organisatorischer Rückblick • Planung weiterer Schritte

  3. Beispielapplikation • Digitaler Bilderrahmen • Anzeigen von Bitmapbildern auf SD-Karte • Abspielen von Hintergrundsound von SD-Karte • Steuern der Bilderabfolge durch Tastendrücke • _ Vorwärts • _ Rückwärts • _ Slideshow

  4. Architekturentwurf

  5. Rechte von Prozessen • 3 Privilegienstufen • Kernel darf alles • Unprivilegierte Prozesse • eingeschränkte SysCall API • kein Zugriff auf Hardware • Priviligierte Prozesse • volle SysCall API • können Privilegien vererben • können andere Prozesse beenden

  6. Kernel • Mikrokernel • Kommunikation aus oberen Schichten via SYSCALLS (static LIB) • Mehr Stabilität und Flexibilität in den oberen Schichten

  7. HAL • Für jede Architektur existiert eine eigene HAL • Funktionen für den Kernel • Ein- bzw. Ausschalten einer Interruptquelle • Hardwaretimer-Interface für Scheduler • Fault-Handler für unkontrollierte Exceptions • Funktionen für die Treiber • Registrierung auf Hardware-Interrupts • IO-Zugriff direkt auf Register • Automatisches PIO Setup für LEDs und Taster • Information über Devices und deren Ressourcen • Schnittstelle für DMA

  8. Treiber und Server • Treiber und Server meist ein Prozess • Kommunikation mit Servern mittels SERVICE CALLS • Treiber kommunizieren mit Kernel mittels SYSCALLS • Möglichst komfortable API für den Programmierer (static LIB)

  9. Sound Server und Treiber • Treiber und Server sind ein Prozess • Schnittstelle zum Sound-Chip und dem Audioausgang • Kein Buffering und Prefetching • LOAD(FILENAME) • PLAY() • PAUSE() • STOP() • SETVOLUME(LEVEL)

  10. Bootprozess • startup_init (Generelles Hardware-Setup) • intmaindes Kernels • HAL initialisieren • InterruptHandler / Clock / Scheduler starten • IPC und Memory Management initialisieren • InitProcess starten • Treiber/Server starten • Eingebaute Programme starten (Shell…)

  11. Scheduling • Anforderungen an den Scheduler • Minimale Latenzzeit(Antwort bzw Jobfertigstellungszeit) • Maximaler Jobdurchsatz • Maximaler Ausnutzungsgrad(I/O-Geräte müssen maximal ausgenutzt werden) • Fairness(Jeder Job bekommt Ausführungszeit, keiner verhungert)

  12. Scheduling • Verfahren in Anlehnung an Round Robin • Viele Prozesse in RUNNABLE Status • Welcher Prozess wird ausgeführt, wenn Prioritäten benutzt werden? • 0 RUNNABLE Prozesse: Starvation(Abhilfe durch IDLE Prozess) • 1 RUNNABLE Prozess: Einfach • > 1 RUNNABLE Prozesse: ? Runnable Dead Running Dead Blocked Zombie

  13. Scheduling • Präemptives Round Robin mit mehreren Queues für Prioritäten • Clock gibt Ticks über Interrupt • Quantum muss festgelegt werden • Tradeoff: Responsiveness vs. Scheduler Rechenzeit • Tannenbaum empfiehlt 100ms 7 /10 P P P P P P P P P P P HIGH-Priority . . . 2 /10 P P P P P P P P P P P 1 /10 P P P P P P P P P P P LOW-Priority

  14. Scheduling • Speicherbedarf abhängig von • Maximaler Anzahl Prozesse • Anzahl Queues • Bei max. 256 Prozessen und drei Queues • 23.5 KB (24098 Bytes) • Bei max. 64 Prozessen und drei Queues • 6 KB (6050 Bytes)

  15. Scheduling • Aufwände für Operationen • Anlegen eines neuen Prozesses • Maximal O(Anzahl Prozesse) • Mininmal Ω(1) • In der Regel: O(Anzahl Prozesse / 2) • Rescheduling • O(Anzahl der Prozesse) • Jedoch Zugriff auf Prozesse, Prozessswitches etc O(1)

  16. Scheduling • Problem ? • Abhilfen • Response Ratio berechnen • Gewichtung der Prioritäten nach Anzahl Prozesse in der Queue

  17. Scheduling und Echtzeit • Verfahren für harte Echtzeit scheinen nur wenig relevant • Rate Monotonic Scheduling • Deadline Monotonic Schedulingoptimiert für periodische Prozesse (Periodendauer = Deadline) • Lösung: RoundRobin welches die Ideen von Highest Response Ratio Next verwendet

  18. Highest Response Ratio Next • Priorität wächst proportional zur Response Ratio t

  19. Interprozesskommunikation • Grundsatzentscheidung: • Shared Memory oder nicht? • Shared Memory ist schnell aber gefährlich • Microkernel soll Stabilität bringen, • deshalb wollen wir auch ein stabiles IPC Lösung: Named Pipes

  20. Simples IPC SoundServer.SetVolume

  21. Simples IPC SoundServer.SetVolume

  22. Simples IPC SoundServer.SetVolume Nachteil des simplen IPC sind die zahlreichen Syscalls Wie können wir Syscalls einsparen und die Kommunikation zwischen den Prozessen beschleunigen?

  23. IPC mit Pipes SoundServer.SetVolume

  24. IPC mit Pipes SoundServer.SetVolume

  25. Pipe Datenstruktur Durch geschickte Wahl der Datenstruktur einer Pipe kann auf ein Synchronisiertes Lesen verzichtet werden: read-pointer write-pointer read-pointer erst NACHLeseoperation erhöhen.Prozess kann unterbrochen werden, kein Überschreiben LA A0 A2 A3 ... Ring-Array - Overhead durch Länge der Message+ Synchronisieren beim Lesen fällt weg Länge der Message A Message A : : B2 B3 ... 4 B0 B1

  26. Interrupt Handling • Hardware-Interrupts werden vom Kernel verwaltet • Treiber können sich auf Interrupt request-# registrieren • Tritt Interrupt auf, wird dieser vom Kernel über IPC anden jeweiligen Treiber geschickt • Kernel quittiert Interrupt • Ausnahme: Interrupts für Clock-Treiber für Scheduler • Interrupt wird in der HAL abgehandelt und eineCallback Methode im Kernel aufgerufen.

  27. Interrupt Handling

  28. Swapping • Problem: Wer übernimmt Swapping/Paging in einem Microkernel • KernelWann (Page fault)Wie (Strategie: z.B.: Least Recently Used) • SD-TreiberPhysikalisches Schreiben und Lesen der PagesDarf nicht ausgelagert werden • Kommunikation über IPCAuszulagernde Page (SD-Queue)Zu ladende Page (SD-Queue)Kernel (Scheduler) übergibt dem SD-Treiber die CPU

  29. Organisatorischer Rückblick • Wöchentliche Dienstagsmeetings • Review der Ergebnisse aus letzter Woche • Besprechung der Wiki-Artikel • Problembereiche identifizieren • Detailresearch • Diskussion in der Gruppe • Neue Aufgabenverteilung für die kommende Woche • Research und Lösen der Aufgaben in Heimarbeit(ggf. in Partnerarbeit falls Themen und Aufgaben verwandt sind)

  30. Organisatorischer Rückblick • Archivierung der Artikel und Ergebnisse mittels Wiki imPM-System www.assembla.com • Historisierung der Artikel • Tickets, Tasks, Messaging Service • Zeiterfassung • Subversion für Source Code und Präsentationen, Grafiken… • Automatische Email-Generierung an alle/bestimmte Mitglieder

  31. Planung weiterer Schritte • Timebox 2 (bis 9.12.) • Implementierung des Betriebssystemkerns • Vollständiger Kernel, RS232 Server und Shell • Geschätzter Implementierungsaufwand 201 Stunden • Timebox 3 (bis 20.01.) • Implementierung der Treiber und Server, Beispielapplikation und erweiterte Funktionalitäten (DMA, Swapping…) • Geschätzter Implementierungsaufwand 225 Stunden

More Related