kreative OS Betriebssystem Projekt Ubiquitous Computing II (WS 2009)

Transkript

1 kreative OS Betriebssystem Projekt Ubiquitous Computing II (WS 2009) Sylvia Nischkowski Daniel Kuster Florian Schmid Matthias Gsteu Anton Biller

2 Überblick 1.Anforderungen 2.Struktur 3.Entwicklung 2

3 1. Anforderungen Anforderungen an das kos Betriebssystem Anforderungen durch AvRGUS Applikation 3

4 1. Anforderungen Anforderungen an kos Multitasking Prozesse, keine Threads Anwendungen Laden ELF-Loader, Laden von SD-Karte Device Drivers Treiber-Struktur Performance Counters 4

5 1. Anforderungen Anforderungen an kos (2) Speichertrennung, Speicherschutz über MMU private Mode IPC minimal mittels Semaphoren Portierbarkeit HAL 5

6 1. Anforderungen Anforderungen durch AvRGUS Überwachungssoftware als Demo- Applikation Darstellung von Bildern auf Display Display-Treiber, Bitmap-API Bilddaten ü ber eine Schnittstelle empfangen MMC-Treiber (SD-Karte), FAT 6

7 Überblick 1.Anforderungen 2.Struktur 3.Entwicklung 7

8 Architektur Applikationen Treiberstruktur Asynchrones IO (USART) Memory Management Prozesse Performance Counters Loader 8

9 Architektur 9

10 Architektur (2) Monolithischer Kernel Performanz Schnelle Ergebnisse ohne IPC Schichtenarchitektur Abhängigkeiten nur in eine Richtung Austauschbarkeit Geringere Komplexität 10

11 Architektur (3) Ordnerstruktur High-Level-Treiber Low-Level-Treiber Treiber Protokolle Kernel Usermode Kernelmode Usermode Kernelmode kos-api Usermode 11

12 Architektur (4) Verbesserungen: Abhängigkeiten (API, Teiber,...) für Applikationen in Ordnerstruktur berücksichtigen 12

13 Applikationen 13

14 Applikationen (2) Geladen von SD-Karte Konsole AvRGUS Kompiliert als eigenständiges ELF-File Inkludiert High-Level-Treiber, kos-api Applikations-Linker- und Startup-Script 14

15 Konsole Besteht aus mehreren Modulen Parser, Interpreter und Formatter Einfach erweiterbar I/O über serielle Schnittstelle 9 Befehle verfügbar, letzter Befehl gepuffert Startet Applikationen als eigene Prozesse (Demo) 15

16 Konsole Verbesserungen: Befehlspuffer vergrößern Befehle als eigene Prozesse Funktionsumfang erweitern Mehr spezielle Zeichen verarbeiten (z.b Tabulator Auto-Vervollständigung) 16

17 AvRGUS Bildverarbeitungsapplikation Lädt Bilder (Bitmap) der SD-Karte Färbt Bilddifferenz ein Differenzbild mit Transparenz Nutzt Alpha-Blending des Low-level- Treibers (Demo) 17

18 AvRGUS Verbesserungen: Modularisierung (Pipes-And-Filters) Komplexeres IPC vorausgesetzt würde von Double-Buffering und DMA profitieren 18

19 Treiberstruktur 19

20 Treiberstruktur (2) Trennung in High- und Low-Level-Treiber High-Level-Treiber im Usermode Verwendet von Applikationen Hardware-unabhängig Low-Level-Treiber im Kernelmode Hardware-spezifisch 20

21 Treiberstruktur (3) High-Level-Treiber allokiert Protokolldaten Usermode Kernelmode verwendet gesendet an befüllt Protokollschema definiert Low-Level-Treiber Hardware 21

22 Asynchrones I/O 22

23 Asynchrones I/O (2) Beispiel USART Low-Level-Treiber: Puffer für eingehende und ausgehende Daten High-Level-Treiber schreibt und liest aus Puffer Interrupts lösen Schreib- und Lesevorgänge auf Hardwareseite aus 23

24 Asynchrones I/O (3) Schreibvorgang High-Level-Treiber Low-Level-Treiber Hardware write(data) success buffer(data) enable interrupt() interrupt(hardware-ready) send(data) Usermode Kernelmode buffer-- 24

25 Asynchrones I/O (3) Schreibvorgang schlägt fehl, Puffer voll High-Level-Treiber Low-Level-Treiber Hardware write(data) buffer full write(data) buffer full write(data) buffer full enable interrupt() enable interrupt() enable interrupt() Usermode Kernelmode 25

26 Asynchrones I/O (4) Problem: Blockierende Aktionen lösen Polling mit Kontextwechsel aus Verbesserung: Resource-Manager Hardware-Callback um Prozesse aufzuwecken 26

27 Asynchrones I/O (5) Verbesserung: Resource-Manager High-Level-Treiber Resource-Manager Low-Level-Treiber Hardware write(data) block(bufferfull) enable interrupt() sleepprocess() Usermode Kernelmode 27

28 Asynchrones I/O (6) Verbesserung: Resource-Manager (2) High-Level-Treiber Resource-Manager Low-Level-Treiber Hardware interrupt() send(data) unblock(bufferfree) buffer-- bufferfull write(data) resumeprocess() Usermode Kernelmode buffer(data) enable interrupt() 28

29 Memory Management 29

30 Memory Management (2) Anforderungen Speicherverwaltung (Fragmentierung) Speicherschutz Paging (MMU private mode) 30

31 Memory Management (3) Inverted page table Kompakt & Performant (Hashfunktion) Translation Lookaside Buffer (TLB) 32 Einträge FIFO Ersetzungsstrategie 31

32 Memory Management (4) kos Betriebssystem Applikation 0x Framebuffer 32

33 Memory Management (5) Verbesserungen: TLB-Ersetzungsstrategie auf LRU Swapping auf SD-Karte 33

34 Prozesse 34

35 Prozesse (2) Scheduling Algorithmus Round-Robin Auswechselbar da abstrahiert über Funktionspointer (Scheduler-Interface) Prozesswechsel Interrupt-Level 0 Sowohl mehr Kontrolle als auch Aufwand 35

36 Prozesse (3) Statusübergänge Runnable Running New Blocked Terminated 36

37 Prozesse (4) Verbesserungen: Weiterer Status für schlafende Prozesse in Verbindung mit Resource-Manager Mehrere Queues im Scheduler (Runnable-Queue, Blocked-Queue,...) 37

38 Performance Counters 38

39 Performance Counters (2) Verwendet werden: BPHR (Branch Prediction Hit Rate) CPI (Cycles Per Instruction) IMR (Instruction TLB Miss Rate) DMR (Data TLB Miss Rate) ICMR (Instruction Cache Miss Rate) DCMR (Data Cache Miss Rate) 39

40 Performance Counters (3) BPHR (Branch Prediction Hit Rate) Verhältnis von Branch-Misspredictions zur Gesamtanzahl ausgewählter Branches Je höher die Branch-Prediction umso schneller kann das System arbeiten Berechnung: Branches executed Branches misspredicted 40

41 Performance Counters (4) CPI (Cycles Per Instruction) Misst durchschnittlichen Zeitaufwand (Cycles) um eine Instruktion auszuführen Berechnung: CPU Clock Cycles Instructions Executed 41

42 Loader 42

43 Loader (2) Vielzahl von Abhängigkeiten Elf-Parser Management Filesystem Elf-File Loader Scheduler... Memory- Process- Elf-File Manager 43

44 Loader (3) Verbesserungen: Berechtigungen auf Segmente setzen Dynamisches Linken, Umgang mit relokierbarer Information 44

45 Überblick 1.Anforderungen 2.Struktur 3.Entwicklung 45

46 3. Entwicklung Hindernisse SCRUM im Einsatz 46

47 3. Entwicklung Hindernisse Unit-Tests zu aufwändig Deployment zeitaufwändig Hardware-Probleme mit Erweiterungsboard und Display zu wenig HW-Erfahrung im Team zu wenig Boards mit Display Abstürze bei JTAGICE mkii durch Timeouts 47

48 3. Entwicklung SCRUM im Einsatz Einsatz ohne Objekt-Orientierung oft nicht problemlos möglich Adaption für Embedded-Entwicklung: User-Stories technische Stories Viele kleine Stories besser plan- und schätzbar weniger Abhängigkeiten 48

49 3. Entwicklung SCRUM im Einsatz (2) Adaption für verteilte Entwicklung: Daily-SCRUM Weekly-SCRUM / Instant-Messenger elektronische Taskliste neben Taskboard 49

50 3. Entwicklung SCRUM im Einsatz (3) Burndown Verlauf Sprint 0 Sprint 1 Sprint 2 Sprint 3 50

51 3. Entwicklung SCRUM im Einsatz (4) Statistik: Gesamtstunden: 1005 Stunden pro Person: 201 Velocity: 18 Storypoints Stories insgesamt: 32 Tasks insgesamt: 90 pro Story: ~3 51

52 3. Entwicklung SCRUM im Einsatz (5) Fazit: + Priorisierung hilfreich + Planning-Poker fördert gemeinsames Verständnis + Aufteilung in Stories und Tasks motivierend (getting things done) + Aufgabenverteilung problemlos möglich 52

53 3. Entwicklung SCRUM im Einsatz (6) Fazit: - neuer Prozess und neues Thema sind gemeinsam große Herausforderung - Technische Stories formulieren war schwierig und zeitaufwendig 53

54 Überblick 1.Anforderungen 2.Struktur 3.Entwicklung 54

55 Vielen Dank für Ihre Aufmerksamkeit! 55