DavidS/zusammenfassungen
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
David Schirrmeister
2024-04-30 09:34:59 +02:00
parent 023db711cf
commit 1749e3dccc
6 changed files with 67 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
Writerside/topics/BS/03_Betriebssysteme_heute.md Normal file
View File

@ -0,0 +1,29 @@
# Betriebssysteme heute
## Einsatzgebiete
- Desktop / Laptop
- Heim- und Büroanwendungen
- Eingebettete Systeme
- Industrieautomation, Fahrzeuge, etc.
- Mobilgeräte
- Smartphones, Tablets, etc.
- Server
- Datacenter, Großrechner, Cloud- / Grid-Computing
## Vielfältige Peripherie
- WLAN, Bluetooth, 3G/5G/5G
- CD, DVD, HDD, SSD, Flash-Memory, USB-Storage
- LCD-/OLED-Displays, Touchscreens
- Keyboard, Mouse, Touchpad
- Drucker, Scanner
- GPS
- Gyroskop
- ...
## Schnittstellen
Zur Vereinfachung der Programmierung existieren spezielle vom Betriebssystem bereitgestellte Funktionen (Systemaufrufe) bspw. für:
- Prozesse
- Dateisystem
- Ein-/Ausgabe
- ...
Standardisierung ([POSIX](06_prozessstruktur.md#posix-api) ermöglicht Portierung von Anwendungen über Plattform-Grenzen hinweg

75
Writerside/topics/BS/04_Betriebssystemkerne.md Normal file
View File

@ -0,0 +1,75 @@
# Betriebssystemkerne
> Gute **Architektur** sagt und _warum_ etwas getan wurde.
> Nicht _wie_ und nicht _wann_ und _wer_.
## Der Betriebssystemkern
- Enthält grundlegende Funktionen des Betriebssystems
- Systemaufrufe
- Benutzerverwaltung
- Prozessverwaltung inklusive Ausführungsreihenfolge ([Scheduling](06_prozessstruktur.md#zeitliche-ausf-hrung-von-prozessen))
- Interprozesskommunikation
- Prozessumschalter ([Dispatcher](06_prozessstruktur.md#zeitliche-ausf-hrung-von-prozessen))
- Gerätetreiber
- [Speicherverwaltung](06_prozessstruktur.md#prozesse-im-speicher)
- Dateisysteme zur Verwaltung von Dateien auf Speicherlaufwerken
- Ist die Schnittstelle zur Hardware des Computers
- Funktionalitäten im BS-Kern haben vollen Hardwarezugriff
- Funktionalitäten laufen als Prozess im Adressraum des Kerns
- Funktionalitäten müssen nicht zwingend im Kern positioniert sein, sie können auch über Dienste bereitgestellt werden (Architektur)
## Übersicht Betriebssystem
![image_17.png](image_17.png)
### Betriebssystemkern
- Der **Kernel-Bereich** ist privilegiert
### Die Anwendungsschicht
- Der **User-Bereich** ist nicht privilegiert, kann aber darauf aufbauende Funktionalitäten bereitstellen
- Zugriff auf die Hardware erfolgt alleinig durch die im _Kernel_ bereitgestellten Funktionalitäten (System-Calls)
## Kernarten
### Monolitische Kerne
Ein Monolith enthält alle Funktionalitäten eines Betriebssystems
| Pro | Con |
|-------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------|
| Bessere **Ausführungsgeschwindigkeit** da weniger _Prozesswechsel_ notwendig sind | Abgestürzte Komponenten des Kerns können nicht separat neu gestartet werden -> können das gesamte BS zum Absturz bringen |
| Durch jahrelange Entwicklungstätigkeit ist eine gewachsene **Stabilität** vorhanden | |
### Minimale Kerne (Microkernel)
Hier befinden sich nur die nötigsten Funktionen im Kernel
| Pro | Con |
|--------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------|
| Alle weiteren Funktionalitäten laufen als _Dienste_ bzw. _Server_ im User-Modus | Abgestürzte Komponenten des Kerns können nicht separat neu gestartet werden -> können das gesamte BS zum Absturz bringen |
| Ausgelagerte Funktionalitäten sind leichter austauschbar, bietet bessere _Stabilität_ und _Sicherheit_ | |
### Hybride Kerne
Enthalten Komponenten, die, aus Geschwindigkeitsgründen, zusätzlich in den Kernel aufgenommen werden
| Pro | Con |
|-------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
| höhere Geschwindigkeit als minimale Kerne | keine klare Definition, was in den Kernel integiert wird |
| höhere Stabilität als monolithische Kerne | Systeme differieren stark -> kann zu einer fehlenden Unterstützung der Hardware- und Software-Hersteller führen |
### Vergleich monolithischer Kern / minimaler Kern
![image_18.png](image_18.png)
## Alternative Architekturen
_Flaschenhals_ alle bestehenden Systeme liegt in ihren Schichtenmodellen
- Anwendung hat _keinen direkten Zugriff auf Hardware_
- _Kommunikation und Datenfluss_ wird über Bibliotheken und deren Kernel abgewickelt
- _Zugangskontrolle_ weiterhin über Bibliotheken und Kernel
## Programmierschnittstellen
**Systemaufruf (System Call)** ist eine API, die es ermöglicht auf Dienste und Ressourcen des BS zuzugreifen
- Implementierung von Systemaufrufen hängt stark von _Hardware_, _Architektur_, _BS_ ab
- ![image_19.png](image_19.png)
- Wann werden die benutzt?
- Berechtigungen, Ressourcenverwaltung, Kommunikation mit Hardware, Prozesssteuerung, Netzwerkkommunikation, Zeitverwaltung
- Nutzung eines direkten Systemaufrufs **nicht empfehlenswert**
- Software ist schlecht portierbar
- Auf Funktionen von Bibliotheken zurückgreifen
- befinden sich mit entsprechenden Wrapper-Funktionen logisch zwischen Benutzer- und BS-Kern

65
Writerside/topics/BS/05_prozesszustaende.md Normal file
View File

@ -0,0 +1,65 @@
# Prozesszustände
- Bereit (Ready)
- Laufend (Running)
- Blockiert (Blocked)
- Beendet (Terminated)
## 2-Zustands-Modell
![image.png](image.png)
Prozesse, die untätig werden, werden in einer Warteschlange gespeichert
- Wird nach Priorität / Wartezeit sortiert
![image_1.png](image_1.png)
#### Pro
- Einfach realisierbar
#### Contra
- Annahme, dass Prozesse jederzeit zur Ausführung bereit sind
- Es gibt blockierte Prozesse
- Wartet auf Ein-/Ausgabe
- Wartet auf Ergebnis eines anderen Prozesses
- Wartet auf Reaktion eines Benutzers
## 3-Zustands-Modell
### Ereignisbezogene Warteschlangen
![image_3.png](image_3.png)
- Für jedes Ereignis, auf welches ein Prozess wartet, gibt es eine Warteschlange
- Tritt das Ereignis ein, werden alle Prozesse der WS in die WS mit den *ready* Prozessen überführt
![image_2.png](image_2.png)
## 5-Zustands-Modell
Anzahl der ausführbaren Prozesse *limitieren*, um Speicher zu sparen
- Zwei weitere Zustände:
- **new (new)**
- Prozesse, deren PCB das Betriebssystem bereits erzeugt hat, aber noch nicht in der Warteschlange sind
- **beendet (exit)**
- Abgearbeitete oder abgebrochene Prozesse, deren PCB und Eintrag noch nicht aus der Prozesstabelle entfernt wurden
![image_4.png](image_4.png)
## 6-Zustands-Modell
Falls nicht genügend physischer Hauptspeicher für alle Prozesse:
- **Auslagerungsspeicher (Swap)**
- Zustand: **suspendiert (suspended)**
- dadurch steht den Prozessen in den Zuständen _rechnend_ und _bereit_ mehr Hauptspeicher zur Verfügung
![image_5.png](image_5.png)
## 7-Zustands-Modell
![image_6.png](image_6.png)
## Zustands-Modell von Linux
- ähnlich wie [7-Zustands-Modell](#7-zustands-modell)
- Zustand _rechnend_:
- **benutzer rechnend (user running)**
- Prozesse im Benutzermodus
- **kernel rechnend (kernel running)**
- Prozesse im Kernel-Modus
- Zustand _beendet (exit)_ = _Zombie_
- ist fertig abgearbeitet
- Eintrag in der Prozesstabelle existiert noch bis Elternprozess den Rückgabewert abgefragt hat#
![image_7.png](image_7.png)

75
Writerside/topics/BS/06_prozessstruktur.md Normal file
View File

@ -0,0 +1,75 @@
# Prozessstruktur
## Prozessdarstellung
- Umfasst [_Zustände_](05_prozesszustaende.md) und _Struktur_ eines laufenden Programms
- Grundlegende Komponenten, die die _Speicherrepräsentation_ eines Prozesses vorhanden sein können
- Systemumgebung
- Stack
- Heap
- BSS (Block Started by Symbol)
- Datensegment
- Codesegment
- ![image_8.png](image_8.png)
Beispiel: Terminalbefehl **- size**
- ![image_9.png](image_9.png)
## Prozesse im Speicher
- ![image_10.png](image_10.png)
- Ablage im physischen Speicher erfolgt in nicht fortlaufender Weise durch den virtuellen Speicher
- nicht zwangsläufig ständig im Hauptspeicher
## Erzeugung von Prozesskopien
- Systemaufruf **fork** unter Linux/Unix
- Erzeugung einer _identischen Kopie_ eines Prozesses
- aufrufender Prozess: _Elternprozess (Parent Process)_
- neuer Prozess: _Kind-Prozess_ (Child Process)
- hat gleichen _Programmcode_ und _Befehlszähler_
- verweist auf gleiche Zeile im Programmcode
- Speicherbereiche von Kind- und Elternprozess streng getrennt
- ![image_11.png](image_11.png)
## Erzeugung von neuen Prozessen
- Systemaufruf **exec**
- Ersetzt bestehenden Prozess durch einen anderen
- neuer Prozess erbt PID des aufrufenden Prozesses
- ![image_12.png](image_12.png)
- Soll aus einem Prozess (_bspw. Kommandozeilen-Interpreter (Shell)_) heraus ein Programm gestartet werden:
- _fork_ -> _exec_
- ![image_13.png](image_13.png)
## Übersicht Erzeugung/Verkettung/Vergabelung
![image_14.png](image_14.png)
## Beenden von Prozessen
Arten des Beendens:
- Normales Beenden (freiwillig, im Code definiert)
- Beenden aufgrund eines Fehlers (freiwillig, im Code definiert)
- Beenden aufgrund eines schwerwiegenden Fehlers (unfreiwillig, durch BS)
- Beenden durch einen anderen Prozess (unfreiwillig)
Unix Befehl: **kill** erstellt einen Wrapper um BS-Aufruf _kilL()_
- ist auf jedem Unix als alleinstehende Anwendung vorhanden (_/bin/kill_)
## Zeitliche Ausführung von Prozessen
- **Scheduler** ist wichtige Komponente des Betriebssystems
- Zuständig für Zuweisung von CPU-Ressourcen an laufenden Prozessen
- Hauptaufgabe: _Reihenfolge_ festlegen
- **Dispatcher**: Umsetzung der Scheduling-Entscheidungen
- Implementierung der Entscheidung
- Wechsel des _Kontrollflusses_ von einem laufenden Prozess zu einem anderen
- Einleiten des Umschaltens durch einen _Timer-Interrupt_
- Interrupt wird periodisch ausgelöst und startet entsprechende Softwareroutine
- ![image_15.png](image_15.png)
- ![image_16.png](image_16.png)
## POSIX-API
_Portable Operating System Interface_
- Standard, der von der IEE(_Institute of Electrical and Electronics Engineers_) entwickelt wurde
- Definiert Schnittstelle zwischen Anwendung und Betriebssystem
- erleichtert Portabilität von Software zwischen verschiedenen Unix BS
- bspw:
- fork, wait/waitpid, sleep, getpid/getppid/setpgid, execl/execv/execve, kill, ...