TockOS Hail - Revision history

Wolfm: /* TockOS */

2022-11-08T12:26:00Z

TockOS

← Older revision		Revision as of 12:26, 8 November 2022
Line 8:		Line 8:
	1. Compile-Time Memory-Safety durch den Rust Compiler,		1. Compile-Time Memory-Safety durch den Rust Compiler,

	2. Nutzung von Speicherschutzeinheiten (u.a. auf Hardwareebene) um Anwendungen vom Kernel zu isolieren.		2. Nutzung von Speicherschutzeinheiten (u.a. auf Hardwareebene), um Anwendungen vom Kernel zu isolieren.

Wolfm: /* Hail Board */

2022-10-18T14:12:41Z

Hail Board

← Older revision		Revision as of 14:12, 18 October 2022
Line 240:		Line 240:
	== Hail Board ==		== Hail Board ==

	Hail ist ein speziell für Tock im Jahre 2017 entwickeltes Board für IoT-Development. Es operiert mit dem vollständig in Rust geschriebenen Open-Source Betriebssystem TockOS. Zudem ~~exisiert~~ auch ein in Rust geschriebener [https://github.com/tock/tock-bootloader/tree/master/boards/hail-bootloader Bootloader] für dieses Board, welcher allerdings ~~augrund~~ eines zu hohen Aufwands für die Entwickler nicht mehr Open-Source verfügbar ist.		Hail ist ein speziell für Tock im Jahre 2017 entwickeltes Board für IoT-Development. Es operiert mit dem vollständig in Rust geschriebenen Open-Source Betriebssystem TockOS. Zudem existiert auch ein in Rust geschriebener [https://github.com/tock/tock-bootloader/tree/master/boards/hail-bootloader Bootloader] für dieses Board, welcher allerdings aufgrund eines zu hohen Aufwands für die Entwickler nicht mehr Open-Source verfügbar ist.

Wolfm: /* libtock-c */

2022-10-18T14:10:09Z

libtock-c

← Older revision		Revision as of 14:10, 18 October 2022
Line 155:		Line 155:
	== libtock-c ==		== libtock-c ==

	Die Bibliothek libtock-c ermöglicht es, Anwendungen für TockOS in C zu schreiben, indem dafür die notwendigen C-Bindings zur Verfügung gestellt werden. Dabei werden bereits einige Beispiele für Anwendungen bereitgestellt, welche direkt kompiliert und über den Tockloader installiert werden können. Die libtock-c basiert auf einer eigenen Implementierung der C-Standardbibliothek für Embedded-Systeme, welche auf den Namen 'newlib' getauft wurde und mit der libtock-c mitgeliefert wird. Von daher ist es ~~inherent~~ nicht möglich, den POSIX-Standard zu nutzen bzw. zu gewähren während der Entwicklung von Anwendungen mit dieser Bibliothek. Zusätzlich gibt es noch Erweiterungen für Lua und C++, welche ebenfalls direkt mitgeliefert werden.		Die Bibliothek libtock-c ermöglicht es, Anwendungen für TockOS in C zu schreiben, indem dafür die notwendigen C-Bindings zur Verfügung gestellt werden. Dabei werden bereits einige Beispiele für Anwendungen bereitgestellt, welche direkt kompiliert und über den Tockloader installiert werden können. Die libtock-c basiert auf einer eigenen Implementierung der C-Standardbibliothek für Embedded-Systeme, welche auf den Namen 'newlib' getauft wurde und mit der libtock-c mitgeliefert wird. Von daher ist es inhärent nicht möglich, den POSIX-Standard zu nutzen bzw. zu gewähren während der Entwicklung von Anwendungen mit dieser Bibliothek. Zusätzlich gibt es noch Erweiterungen für Lua und C++, welche ebenfalls direkt mitgeliefert werden.


Line 201:		Line 201:
	</syntaxhighlight>		</syntaxhighlight>

	Um nun Applikationen auch extern entwickeln zu können, also außerhalb des libtock-c Verzeichnisses, ist lediglich eine Änderung der Pfadvariable <code>TOCK_USERLAND_BASE_DIR</code> auf die entsprechende Stelle notwendig, in der die libtock-c liegt. Dort liegen die notwendigen Makefiles, um die Applikation erfolgreich zu ~~komplieren~~ und das TAB (Tock Application Bundle) zu bauen.		Um nun Applikationen auch extern entwickeln zu können, also außerhalb des libtock-c Verzeichnisses, ist lediglich eine Änderung der Pfadvariable <code>TOCK_USERLAND_BASE_DIR</code> auf die entsprechende Stelle notwendig, in der die libtock-c liegt. Dort liegen die notwendigen Makefiles, um die Applikation erfolgreich zu kompilieren und das TAB (Tock Application Bundle) zu bauen.

	== libtock-rs ==		== libtock-rs ==

Wolfm: /* TockOS */

2022-10-18T14:07:35Z

TockOS

Kaufmanf: /* BLE API für Rust */

2022-10-17T17:49:55Z

BLE API für Rust

← Older revision		Revision as of 17:49, 17 October 2022
Line 360:		Line 360:
	== BLE API für Rust ==		== BLE API für Rust ==

	In der libtock-c gibt es eine API für das Bluetooth-Radio, die es in der libtock-rs nicht gibt. Um das Bluetoothradio angemessen zu verwenden, benötigt man jedoch einen vollständigen Bluetooth-Stack, welcher in der libtock-c durch ~~libnrfserialization~~ mitgeliefert wird -- einen entsprechenden Bluetooth-Stack in Rust gibt es in dieser Form nicht: Da das Bluetoothradio nicht in den Prozessor integriert ist, kommuniziert dieser über SPI mit dem Radio, was nur mit einer Aufspaltung in Pakete funktioniert. Dies ist im Serialisierungsteil der Library implementiert, welcher als "Backend" fungiert und auf Tock ausgelegt ist. Aufgrund der Spezifizität der Anwendung für diese ~~Library~~ ist es naheliegend, dass ein Port in Rust nicht existiert, also die libtock-rs auf eine Implementierung des Bluetooth-Stacks derzeit verzichten muss.		In der libtock-c gibt es eine API für das Bluetooth-Radio, die es in der libtock-rs nicht gibt. Um das Bluetoothradio angemessen zu verwenden, benötigt man jedoch einen vollständigen Bluetooth-Stack, welcher in der libtock-c durch libnrf-serialization mitgeliefert wird -- einen entsprechenden Bluetooth-Stack in Rust gibt es in dieser Form nicht. Da das Bluetoothradio nicht in den Prozessor integriert ist, kommuniziert dieser über SPI mit dem Radio, was nur mit einer Aufspaltung in Pakete funktioniert. Dies ist im Serialisierungsteil der Library implementiert, welcher als "Backend" fungiert und auf Tock ausgelegt ist. Aufgrund der Spezifizität der Anwendung für diese Bibliothek ist es naheliegend, dass ein Port in Rust nicht existiert, also die libtock-rs auf eine Implementierung des Bluetooth-Stacks derzeit verzichten muss.
	Darüber noch in Unkenntnis befindlich haben wir uns jedoch der Aufgabe angenommen, wenigstens eine Implementierung der Bluetoothradio-Syscalls in die libtock-rs einzufügen. Diese entsprechen in etwa der C-API, jedoch mit für Rust idiomatischerem Handling von Buffern und Callbacks:		Darüber noch in Unkenntnis befindlich haben wir uns jedoch der Aufgabe angenommen, wenigstens eine Implementierung der Bluetoothradio-Syscalls in die libtock-rs einzufügen. Diese entsprechen in etwa der C-API, jedoch mit für Rust idiomatischerem Handling von Buffern und Callbacks:

Line 392:		Line 392:
	</syntaxhighlight>		</syntaxhighlight>

	Um das Bluetoothradio in C zu verwenden, genügt es, den simple_ble.h-Header zu verwenden, der einfache Funktionalität wie das Advertisen von Sensordaten ermöglicht, ein Beispiel hierzu findet man in libtock-c/examples/services/ble-env-sensing.		Um das Bluetoothradio in C zu verwenden, genügt es, den <code>simple_ble.h</code> Header zu verwenden, der einfache Funktionalität wie das Advertisen von Sensordaten ermöglicht, ein Beispiel hierzu findet man in <code>libtock-c/examples/services/ble-env-sensing</code>.


	== References ==		== References ==

Kaufmanf: /* Hail Board */

2022-10-17T17:44:51Z

Hail Board

← Older revision		Revision as of 17:44, 17 October 2022
Line 240:		Line 240:
	== Hail Board ==		== Hail Board ==

	Hail ist ein speziell für Tock im Jahre 2017 entwickeltes Board für IoT-Development. Es operiert mit dem vollständig in Rust geschriebenen ~~open~~-~~source~~ Betriebssystem TockOS. Zudem exisiert auch ein in Rust geschriebener [https://github.com/tock/tock-bootloader/tree/master/boards/hail-bootloader Bootloader] für dieses Board, welcher allerdings augrund eines zu hohen Aufwands für die Entwickler nicht mehr ~~open~~-~~source~~ verfügbar ist.		Hail ist ein speziell für Tock im Jahre 2017 entwickeltes Board für IoT-Development. Es operiert mit dem vollständig in Rust geschriebenen Open-Source Betriebssystem TockOS. Zudem exisiert auch ein in Rust geschriebener [https://github.com/tock/tock-bootloader/tree/master/boards/hail-bootloader Bootloader] für dieses Board, welcher allerdings augrund eines zu hohen Aufwands für die Entwickler nicht mehr Open-Source verfügbar ist.


Line 263:		Line 263:
	\| FXOS8700CQ 6-axis Accelerometer and Magnetometer \|\| 6-axis e-compass (<math>\plusmn 1200 \mu</math>T range), <math>\plusmn 8g</math> acceleration, ODR 1.5 Hz - 800 Hz \|\| Sensor zur Bestimmung von Drehungen, Geschwindigkeit etc. Andwendung für digitale Kompasse, Bewegungserkennung oder Erkennung der Orientierung des Geräts. \|\| [https://www.nxp.com/docs/en/data-sheet/FXOS8700CQ.pdf Dokumentation]		\| FXOS8700CQ 6-axis Accelerometer and Magnetometer \|\| 6-axis e-compass (<math>\plusmn 1200 \mu</math>T range), <math>\plusmn 8g</math> acceleration, ODR 1.5 Hz - 800 Hz \|\| Sensor zur Bestimmung von Drehungen, Geschwindigkeit etc. Andwendung für digitale Kompasse, Bewegungserkennung oder Erkennung der Orientierung des Geräts. \|\| [https://www.nxp.com/docs/en/data-sheet/FXOS8700CQ.pdf Dokumentation]
	\|-		\|-
	\| RGB LED \|\| 3 LEDs (R,G,B) \|\| Ansteuerbare LED mit 3 Kanälen (rot,grün,blau) \|\| -		\| RGB LED \|\| 3 LEDs (R,G,B) \|\| Ansteuerbare LED mit 3 Kanälen (rot, grün, blau) \|\| -
	\|-		\|-
	\| User push-button \|\| - \|\| Programmierbarer Knopf (sehr klein) \|\| -		\| User push-button \|\| - \|\| Programmierbarer Knopf (sehr klein) \|\| -
Line 278:		Line 278:
	! Label !! Beschreibung		! Label !! Beschreibung
	\|-		\|-
	\| A0-A5 \|\| Analog-to-Digital Pin,		\| A0-A5 \|\| (ADC) Analog-to-Digital Pin
	\|-		\|-
	\| DAC \|\| Digital-to-Analog Output, kann als digitaler Pin oder DAC genutzt werden		\| DAC \|\| Digital-to-Analog Output, kann als digitaler Pin oder DAC genutzt werden
Line 290:		Line 290:
	\| GND \|\| Ground-Pin, für Spannungmessung		\| GND \|\| Ground-Pin, für Spannungmessung
	\|-		\|-
	\| VIN \|\| Input/output Pin mit (3.6-)		\| VIN \|\| Input/output Pin mit 3.6-4.8 V Grundspannung
	\|-		\|-
	\| D0-D7 \|\| Digitale GPIO Input Pins, alternativ auch digitale GPIO Pins		\| D0-D7 \|\| Digitale GPIO Input Pins, alternativ auch digitale GPIO Pins
	\|-		\|-
Line 307:		Line 307:
	Über GPIO (General Purpose Input/Output) lassen sich die einzelnen Pins im Programm ansteuern. Dabei scheint es mehrere Modis zu geben, in denen die Konfiguration der Pins laufen kann:		Über GPIO (General Purpose Input/Output) lassen sich die einzelnen Pins im Programm ansteuern. Dabei scheint es mehrere Modis zu geben, in denen die Konfiguration der Pins laufen kann:

	* JTAG (Joint Test Action Group): Debug- und Testmodus für Hardware und integrierte Schaltungen. Damit können einzelne Komponenten auf Funktionalität getestet werden wobei spezielle Teile ~~von~~ ICs erst dann aktiviert werden.		* JTAG (Joint Test Action Group): Debug- und Testmodus für Hardware und integrierte Schaltungen. Damit können einzelne Komponenten auf Funktionalität getestet werden, wobei spezielle Teile des ICs (Integrated Circuits) erst dann aktiviert werden.

	* SPI1 (Serial Peripheral Interface): Hierbei handelt es sich um ein Bus-System, mit dem digitale Schaltungen nach dem Master-Slave-System miteinander verbunden werden können. Dabei können viele Teilnehmer gleichzeitig über diesen Bus verbunden werden und der Master legt fest, mit welchem Slave er dabei kommunizieren will.		* SPI1 (Serial Peripheral Interface): Hierbei handelt es sich um ein Bus-System, mit dem digitale Schaltungen nach dem Master-Slave-System miteinander verbunden werden können. Dabei können viele Teilnehmer gleichzeitig über diesen Bus verbunden werden und der Master legt fest, mit welchem Slave er dabei kommunizieren will.
Line 313:		Line 313:
	* TIM3: General Purpose Timer		* TIM3: General Purpose Timer

	Dabei ist es uns gelungen, in der aktuellen ~~Konfugration~~ die Pins D0,D1,D6 und D7 anzusteuern. Die Pins D2 und D5 waren immer aktiv dabei.		Dabei ist es uns gelungen, in der aktuellen Konfiguration die Pins D0, D1, D6 und D7 anzusteuern. Die Pins D2 und D5 waren immer aktiv dabei mit einer konstanten Spannung von 3.3V.

	Die Pins lassen sich folgendermaßen über das GPIO-Interface ansteuern ~~dabei~~:		Die Pins lassen sich folgendermaßen über das GPIO-Interface ansteuern:

	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">
Line 342:		Line 342:
	</syntaxhighlight>		</syntaxhighlight>

	Dabei haben sich folgende Pins mit einem bestimmten Index ansteuern lassen:		Dabei haben sich folgende Pins mit einem bestimmten Index ansteuern lassen, welche der Funktion in GPIO übergeben werden müssen:

	{\| class="wikitable"		{\| class="wikitable"

Kaufmanf: /* libtock-c */

2022-10-17T17:34:58Z

libtock-c

← Older revision		Revision as of 17:34, 17 October 2022
Line 155:		Line 155:
	== libtock-c ==		== libtock-c ==

	Die ~~Blbiothek~~ libtock-c ermöglicht es, Anwendungen ~~in C~~ für TockOS zu schreiben, indem dafür die notwendigen C-Bindings zur Verfügung gestellt werden. Dabei werden bereits einige Beispiele für Anwendungen bereitgestellt, welche direkt kompiliert und ~~direkt~~ über den Tockloader installiert werden können. Die libtock-c ~~baisert~~ auf einer eigenen Implementierung der C-Standardbibliothek für Embedded-Systeme, welche auf den Namen 'newlib' getauft wurde und mit der libtock-c mitgeliefert wird. Von daher ist es inherent nicht möglich, den POSIX-Standard ~~einzuhalten~~ während der Entwicklung von Anwendungen mit dieser Bibliothek. Zusätzlich gibt es noch Erweiterungen für Lua und C++, welche ebenfalls direkt mitgeliefert werden.		Die Bibliothek libtock-c ermöglicht es, Anwendungen für TockOS in C zu schreiben, indem dafür die notwendigen C-Bindings zur Verfügung gestellt werden. Dabei werden bereits einige Beispiele für Anwendungen bereitgestellt, welche direkt kompiliert und über den Tockloader installiert werden können. Die libtock-c basiert auf einer eigenen Implementierung der C-Standardbibliothek für Embedded-Systeme, welche auf den Namen 'newlib' getauft wurde und mit der libtock-c mitgeliefert wird. Von daher ist es inherent nicht möglich, den POSIX-Standard zu nutzen bzw. zu gewähren während der Entwicklung von Anwendungen mit dieser Bibliothek. Zusätzlich gibt es noch Erweiterungen für Lua und C++, welche ebenfalls direkt mitgeliefert werden.


Line 201:		Line 201:
	</syntaxhighlight>		</syntaxhighlight>

	Um nun Applikationen auch extern entwickeln zu können, also außerhalb des libtock-c Verzeichnisses, ist lediglich eine Änderung der Pfadvariable <code>TOCK_USERLAND_BASE_DIR</code> auf die entsprechende Stelle notwendig, in der die libtock-c liegt. Dort liegen die notwendigen Makefiles, um die Applikation erfolgreich zu komplieren und zu bauen.		Um nun Applikationen auch extern entwickeln zu können, also außerhalb des libtock-c Verzeichnisses, ist lediglich eine Änderung der Pfadvariable <code>TOCK_USERLAND_BASE_DIR</code> auf die entsprechende Stelle notwendig, in der die libtock-c liegt. Dort liegen die notwendigen Makefiles, um die Applikation erfolgreich zu komplieren und das TAB (Tock Application Bundle) zu bauen.

	== libtock-rs ==		== libtock-rs ==

Kaufmanf: /* Tockloader */

2022-10-17T17:30:41Z

Tockloader

← Older revision		Revision as of 17:30, 17 October 2022
Line 103:		Line 103:
	== Tockloader ==		== Tockloader ==

	Der Tockloader dient dazu, kompilierte Binärdateien auf den Flash-Speicher eines Chips zu laden. Außerdem kann darüber ~~weiterhn~~ mit TockOS kommuniziert werden, welches ebenfalls auf einem solchen Chip laufen muss.		Der Tockloader dient dazu, kompilierte Binärdateien auf den Flash-Speicher eines Chips zu laden. Außerdem kann darüber weiterhin mit TockOS kommuniziert werden, welches ebenfalls auf einem solchen Chip laufen muss.

	'''Initialisierung (Linux)'''		'''Initialisierung (Linux)'''
Line 119:		Line 119:


	'''~~Compile~~ Kernel'''		'''Kernel Kompilieren'''

	Zusätzlich kann man noch den Tock-Kernel installieren und kompilieren, um ggf. den Kernel auf dem Board zu updaten:		Zusätzlich kann man noch den Tock-Kernel installieren und kompilieren, um ggf. den Kernel auf dem Board zu updaten:
Line 139:		Line 139:
	Hier sind ein paar nützliche Befehle aufgelistet, um Apps mithilfe des Tockloaders mit libtock-c zu installieren/deinstallieren und den Status des Systems abzufragen:		Hier sind ein paar nützliche Befehle aufgelistet, um Apps mithilfe des Tockloaders mit libtock-c zu installieren/deinstallieren und den Status des Systems abzufragen:

	* Apps installieren: <code>$ tockloader install</code>		* Apps installieren: <code>$ tockloader install </code>

			* Apps deinstallieren: <code>$ tockloader install [name] </code>

			* Apps aktualisieren: <code>$ tockloader update [name] </code>

	* Apps deinstallieren (löscht alle installierten Apps): <code>$ tockloader erase-apps</code>		* Apps deinstallieren (löscht alle installierten Apps): <code>$ tockloader erase-apps</code>

Kaufmanf: /* TockOS */

2022-10-17T17:25:37Z

TockOS

Kaufmanf: /* TockOS */

2022-10-17T17:05:56Z

TockOS

← Older revision		Revision as of 17:05, 17 October 2022
Line 4:		Line 4:
	'''Idee'''		'''Idee'''

	Bei Tock handelt es sich um ein open-source Betriebssystem für den Embedded-Bereich, welches u.a. Plattformen wie Cortex-M und RISCV unterstützt. Besonders dabei ist, dass dabei der Kernel als auch die Treiber in der Programmiersprache Rust geschrieben sind. Dabei werden die Speicherschutzmechanismen von Rust genutzt, um für Safety und Security innerhalb des Kernels aber auch der Anwendungen zu gewährleisten. Dabei sind 2 Techniken für den Speicherschutz besonders hervorzuheben:		Bei Tock handelt es sich um ein open-source Betriebssystem für den Embedded-Bereich, welches u.a. Plattformen wie Cortex-M und RISCV unterstützt. Besonders dabei ist, dass dabei der Kernel als auch die Treiber in der Programmiersprache Rust geschrieben sind. Hinzu kommt die Schwierigkeit, dass Tock die limitierten Systemressourcen sinnvoll und effizient verwalten muss, da im Embedded-Bereich die Systemressourcen sehr minimalistisch gehalten werden. Dabei werden die Speicherschutzmechanismen von Rust genutzt, um für Safety und Security innerhalb des Kernels aber auch der Anwendungen zu gewährleisten. Dabei sind 2 Techniken für den Speicherschutz besonders hervorzuheben:

	1. Compile-Time Memory-Safety durch den Rust Compiler		1. Compile-Time Memory-Safety durch den Rust Compiler

← Older revision		Revision as of 14:07, 18 October 2022
Line 4:		Line 4:
	'''Idee'''		'''Idee'''

	Bei Tock handelt es sich um ein ~~open~~-~~source~~ Betriebssystem für den Embedded-Bereich, welches u.a. Plattformen wie Cortex-M und RISCV unterstützt. Besonders dabei ist, dass dabei der Kernel als auch die Treiber in der Programmiersprache Rust geschrieben sind. Hinzu kommt die Schwierigkeit, dass Tock die limitierten Systemressourcen sinnvoll und effizient verwalten muss, da im Embedded-Bereich die Systemressourcen sehr minimalistisch gehalten werden. Dabei werden die Speicherschutzmechanismen von Rust genutzt, um für Safety und Security innerhalb des Kernels aber auch der Anwendungen zu gewährleisten. Dabei sind 2 Techniken für den Speicherschutz besonders hervorzuheben:		Bei Tock handelt es sich um ein Open-Source-Betriebssystem für den Embedded-Bereich, welches u.a. Plattformen wie Cortex-M und RISCV unterstützt. Besonders dabei ist, dass dabei der Kernel als auch die Treiber in der Programmiersprache Rust geschrieben sind. Hinzu kommt die Schwierigkeit, dass Tock die limitierten Systemressourcen sinnvoll und effizient verwalten muss, da im Embedded-Bereich die Systemressourcen sehr minimalistisch gehalten werden. Dabei werden die Speicherschutzmechanismen von Rust genutzt, um für Safety und Security innerhalb des Kernels aber auch der Anwendungen zu gewährleisten. Dabei sind 2 Techniken für den Speicherschutz besonders hervorzuheben:

	1. Compile-Time Memory-Safety durch den Rust Compiler		1. Compile-Time Memory-Safety durch den Rust Compiler,

	2. Nutzung von Speicherschutzeinheiten (u.a. auf Hardwareebene) um Anwendungen vom Kernel zu isolieren		2. Nutzung von Speicherschutzeinheiten (u.a. auf Hardwareebene) um Anwendungen vom Kernel zu isolieren.


Line 17:		Line 17:
	Einzigartig an Tock ist auch das Trust-Modell, wie in der Abbildung zu erkennen ist. Grundsätzlich wird nur den Komponenten des Kernels vertraut, jedoch schon nicht mehr den Treibern oder anderer Software, welche mit noch privilegierten Rechten in sog. "Capsules" laufen. Anwendungen wird grundsätzlich nicht vertraut in dieser Architektur. Allgemein kann festgehalten werden, dass das Hail-Board sowie Tock über keine virtuelle Adressierung verfügt, da wir lediglich eine MPU (Memory Proctection Unit) und keine MMU (Memory Management Unit) zur Verfügung haben.		Einzigartig an Tock ist auch das Trust-Modell, wie in der Abbildung zu erkennen ist. Grundsätzlich wird nur den Komponenten des Kernels vertraut, jedoch schon nicht mehr den Treibern oder anderer Software, welche mit noch privilegierten Rechten in sog. "Capsules" laufen. Anwendungen wird grundsätzlich nicht vertraut in dieser Architektur. Allgemein kann festgehalten werden, dass das Hail-Board sowie Tock über keine virtuelle Adressierung verfügt, da wir lediglich eine MPU (Memory Proctection Unit) und keine MMU (Memory Management Unit) zur Verfügung haben.

	Die Architektur von Tock besteht also mehr oder weniger aus 3 Ebenen, wobei der Kernel die erste Ebene bildet. Im Kernel laufen nur die notwendigsten und ~~esszenziellsten~~ Programme, darunter der Scheduler, die boardspezifische Kernel-Konfiguration sowie das HAL (Hardware Abstraction Layer). Jedes Board besitzt seine eigene Kernel-Konfiguration, in der z.B. auch ~~festegelegt~~ wird, wie der Kernel reagieren soll, wenn eine Anwendung oder Capsule abstürzt. Beim Scheduler handelt es sich bei Tock um einen MLFQ-Scheduler (Multi-Level-Feedback-Queue). Außerdem kann der Kernel durch sog. "Upcalls" mit den Anwendungen im Userland kommunizieren.		Die Architektur von Tock besteht also mehr oder weniger aus 3 Ebenen, wobei der Kernel die erste Ebene bildet. Im Kernel laufen nur die notwendigsten und essenziellsten Programme, darunter der Scheduler, die boardspezifische Kernel-Konfiguration sowie das HAL (Hardware Abstraction Layer). Jedes Board besitzt seine eigene Kernel-Konfiguration, in der z.B. auch festgelegt wird, wie der Kernel reagieren soll, wenn eine Anwendung oder Capsule abstürzt. Beim Scheduler handelt es sich bei Tock um einen MLFQ-Scheduler (Multi-Level-Feedback-Queue). Außerdem kann der Kernel durch sog. "Upcalls" mit den Anwendungen im Userland kommunizieren.

	Die zweite Ebene bilden die Capsules, welche zwischen der Anwendungsebene und dem Kernel leben. Die Capsules an sich unterscheiden sich grundsätzlich von Prozessen, da sie vollkommen anders vom Kernel und Scheduler behandelt werden. Programme in Capsules laufen im privilegierten Modus, dennoch kommt dies mit einigen wichtigen Restriktionen, welche auch der Programmiersprache Rust zugrunde liegen:		Die zweite Ebene bilden die Capsules, welche zwischen der Anwendungsebene und dem Kernel leben. Die Capsules an sich unterscheiden sich grundsätzlich von Prozessen, da sie vollkommen anders vom Kernel und Scheduler behandelt werden. Programme in Capsules laufen im privilegierten Modus, dennoch kommt dies mit einigen wichtigen Restriktionen, welche auch der Programmiersprache Rust zugrunde liegen:

	* Kooperatives Scheduling: Capsules sind nicht preemptiv durch den Scheduler verwaltbar, sodass dieser stets warten muss, bis die Capsule die Kontrolle zurück an den Kernel gibt, wenn deren Operationen vollständig abgeschlossen sind. Das impliziert aber auch, dass falls die Capsule in eine ~~unendlich~~ Schleife gerät, diese für immer läuft, da der Scheduler wartet, bis die Operationen der Capsule abgeschlossen sind.		* Kooperatives Scheduling: Capsules sind nicht preemptiv durch den Scheduler verwaltbar, sodass dieser stets warten muss, bis die Capsule die Kontrolle zurück an den Kernel gibt, wenn deren Operationen vollständig abgeschlossen sind. Das impliziert aber auch, dass falls die Capsule in eine unendliche Schleife gerät, diese für immer läuft, da der Scheduler wartet, bis die Operationen der Capsule abgeschlossen sind.

	* Keine dynamische Speicherallokierung: Die Speicherallokation für Capsules ist statisch und wird mit dem Systemstart festgelegt. Es ist also nicht ohne weiteres möglich, Speicher für Capsules zu allokieren. Dafür werden sog. "Grants" benötigt, welche im Grunde spezielle Speicherregionen innerhalb des Prozessspeichers sind. Diese werden herangezogen, falls Capsules zusätzlichen Speicher benötigen. Die Entscheidung, dass Capsules nicht dynamisch Speicher allokieren können, ist darauf zurückzuführen, dass dem gesamten System nur wenige Kilobyte an Hauptspeicher zur Verfügung stehen, wodurch es für den Kernel durch dynamische Allokationen schwer ist vorherzusagen, wenn der Hauptspeicher erschöpft ist.		* Keine dynamische Speicherallokierung: Die Speicherallokation für Capsules ist statisch und wird mit dem Systemstart festgelegt. Es ist also nicht ohne weiteres möglich, Speicher für Capsules zu allokieren. Dafür werden sog. "Grants" benötigt, welche im Grunde spezielle Speicherregionen innerhalb des Prozessspeichers sind. Diese werden herangezogen, falls Capsules zusätzlichen Speicher benötigen. Die Entscheidung, dass Capsules nicht dynamisch Speicher allokieren können, ist darauf zurückzuführen, dass dem gesamten System nur wenige Kilobyte an Hauptspeicher zur Verfügung stehen, wodurch es für den Kernel durch dynamische Allokationen schwer ist vorherzusagen, wenn der Hauptspeicher erschöpft ist.

	* Kein Unsafe-Rust: Um Memory-Safety in Capsules zu gewährleisten, werden sich die Eigenschaften von Safe Rust zunutze gemacht. So kann schon zur Compile-Time schon festgestellt werden, ob das Programm Memory-Safety erfüllt. Da Unsafe-Rust in Capsules nicht erlaubt ist per Konvention, ist es aber auch nicht möglich, bestimme Programme in Capsules zu schreiben, da wir bestimmte Operationen nur mit Unsafe-Rust ausdrücken können. Dennoch benötigen wir durch Safe Rust keine zusätzlichen Mechanismen, um Memory-Safety zu überprüfen an dieser Stelle.		* Kein Unsafe-Rust: Um Memory-Safety in Capsules zu gewährleisten, werden sich die Eigenschaften von Safe Rust zunutze gemacht. So kann schon zur Compile-Time schon festgestellt werden, ob das Programm Memory-Safety erfüllt. Da Unsafe-Rust in Capsules nicht erlaubt ist per Konvention, ist es aber auch nicht möglich, bestimme Programme in Capsules zu schreiben, da wir bestimmte Operationen nur mit Unsafe-Rust ausdrücken können. Dennoch benötigen wir durch Safe Rust keine zusätzlichen Mechanismen, um Memory-Safety zu überprüfen, an dieser Stelle.

	Zudem kann hier noch erwähnt werden, dass Capsules sich mit dem Kernel einen Stack teilen und auch während der Laufzeit nicht änderbar sind. Das führt aber auch dazu, dass wenn eine Capsule abstürzt bzw. den Kernel-Stack korrumpiert, das System sich davon ~~nich~~ ohne ~~weiteres~~ erholen kann und ein Neustart des Kernels erforderlich ist. Rust liefert hierbei mit seinen eigenen Sicherheitsgarantien die Memory-Safety der Capsules, sodass es keine fehlerhaften Speicherzugriffe während der Laufzeit gibt.		Zudem kann hier noch erwähnt werden, dass Capsules sich mit dem Kernel einen Stack teilen und auch während der Laufzeit nicht änderbar sind. Das führt aber auch dazu, dass wenn eine Capsule abstürzt, bzw. den Kernel-Stack korrumpiert, das System sich davon nicht ohne Weiteres erholen kann und ein Neustart des Kernels erforderlich ist. Rust liefert hierbei mit seinen eigenen Sicherheitsgarantien die Memory-Safety der Capsules, sodass es keine fehlerhaften Speicherzugriffe während der Laufzeit gibt.


	'''Implementierungen'''		'''Implementierungen'''

	Insbesondere existieren bisher 2 Implementierungen von Bibliotheken, welche eine Schnittstelle für die Anwendungsentwicklung in Tock zur Verfügung stellen. Zum einen die [https://github.com/tock/libtock-c libtock-c], welche C-Bindings bereitstellt und die [https://github.com/tock/libtock-rs libtock-rs], welche direkt Rust-Bindings für die ~~Anwendungentwicklung~~ bereitstellt. Dabei ist die Entwicklung in der libtock-c deutlich weiter vorangeschritten als in der in Rust geschriebenen Version, da dort deutlich mehr Bindings für die Features der Systeme und die des Boards bereitgestellt werden.		Insbesondere existieren bisher 2 Implementierungen von Bibliotheken, welche eine Schnittstelle für die Anwendungsentwicklung in Tock zur Verfügung stellen. Zum einen die [https://github.com/tock/libtock-c libtock-c], welche C-Bindings bereitstellt und die [https://github.com/tock/libtock-rs libtock-rs], welche direkt Rust-Bindings für die Anwendungsentwicklung bereitstellt. Dabei ist die Entwicklung in der libtock-c deutlich weiter vorangeschritten als in der in Rust geschriebenen Version, da dort deutlich mehr Bindings für die Features der Systeme und die des Boards bereitgestellt werden.

	Weitere Informationen zu Tock sind in der Dokumentation des [https://github.com/tock/tock Github Repositories von Tock] zu finden.		Weitere Informationen zu Tock sind in der Dokumentation des [https://github.com/tock/tock Github Repositories von Tock] zu finden.
Line 39:		Line 39:
	''' Bootloader '''		''' Bootloader '''

	Zudem ist der Bootloader von Tock ebenfalls in Rust geschrieben, allerdings leider nicht mehr als Open-Source verfügbar für das Hail Board. Als [https://github.com/tock/tock-bootloader/tree/master/boards/hail-bootloader Grund] gaben die Entwickler an, dass es ~~sicht~~ vom Aufwand her nicht lohnt, diesen Bootloader zu warten und zu aktualisieren, da Hail sich auf dem ~~abesteigenden~~ Ast befindet und der Support dafür in Zukunft eingestellt würde. Von daher war es uns nicht möglich, in den Quellcode des Bootloaders zu schauen, der auf diesem Board installiert ist und neue Erkenntnisse dadurch zu gewinnen.		Zudem ist der Bootloader von Tock ebenfalls in Rust geschrieben, allerdings leider nicht mehr als Open-Source verfügbar für das Hail Board. Als [https://github.com/tock/tock-bootloader/tree/master/boards/hail-bootloader Grund] gaben die Entwickler an, dass es sich vom Aufwand her nicht lohnt, diesen Bootloader zu warten und zu aktualisieren, da Hail sich auf dem absteigenden Ast befindet und der Support dafür in Zukunft eingestellt würde. Von daher war es uns nicht möglich, in den Quellcode des Bootloaders zu schauen, der auf diesem Board installiert ist und neue Erkenntnisse dadurch zu gewinnen.


	''' Prozesse und Prozessmanagement'''		''' Prozesse und Prozessmanagement'''

	Prozesse erhalten wie in anderen Betriebssystemen auch einen eigenen Bereich im Hauptspeicher, welcher in im ~~Falle~~ von Tock in folgende Bereiche eingeteilt ist:		Prozesse erhalten wie in anderen Betriebssystemen auch einen eigenen Bereich im Hauptspeicher, welcher im Fall von Tock in folgende Bereiche eingeteilt ist:

	* Grant-Segment: Der Prozess kann auf dieses Segment standardmäßig weder lesend noch schreibend zugreifen. Dieses Segment dient dem Kernel zur Speicherverwaltung von den Capsules, kann aber auch asl Buffer für Daten verwendet werden, die der Prozess dann nutzen ~~Kann~~. In dem Fall ist es dann möglich, über eine <code>allow_readonly()</code> Funktion diese Bereiche für den Prozess lesbar zu machen.		* Grant-Segment: Der Prozess kann auf dieses Segment standardmäßig weder lesend noch schreibend zugreifen. Dieses Segment dient dem Kernel zur Speicherverwaltung von den Capsules, kann aber auch asl Buffer für Daten verwendet werden, die der Prozess dann nutzen kann. In dem Fall ist es dann möglich, über eine <code>allow_readonly()</code> Funktion diese Bereiche für den Prozess lesbar zu machen.

	* Heap-Segment: Das Heap-Segment wird dynamisch allokiert für den Prozess und die Größe dieses Segments wird in der Kernel-~~Konfikuration~~ spezifisch für jedes Board festgelegt.		* Heap-Segment: Das Heap-Segment wird dynamisch allokiert für den Prozess und die Größe dieses Segments wird in der Kernel-Konfiguration spezifisch für jedes Board festgelegt.

	* Daten-Segment: Hier liegen Konstanten und weitere Daten, sowie statische Variablen.		* Daten-Segment: Hier liegen Konstanten und weitere Daten, sowie statische Variablen.
Line 99:		Line 99:
	</syntaxhighlight>		</syntaxhighlight>

	Somit wäre es also leicht möglich, dem Kernel andere Handlungsanweisungen zu geben, falls eine App crasht. Aktuell ist der Panic gesetzt, da es sich hierbei um ein Development Board handelt. Es wäre aber auch ~~einach~~ möglich, ~~das~~ falls eine App crasht, der Prozess, in dem die App läuft, zu terminieren und den Kernel unbeschadet weiterlaufen zu lassen. Diese Einstellungen im Kernel sind spezifisch für jedes Board in einer Konfigurationsdatei editierbar.		Somit wäre es also leicht möglich, dem Kernel andere Handlungsanweisungen zu geben, falls eine App crasht. Aktuell ist der Panic gesetzt, da es sich hierbei um ein Development Board handelt. Es wäre aber auch einfach möglich, dass falls eine App crasht, der Prozess, in dem die App läuft, zu terminieren und den Kernel unbeschadet weiterlaufen zu lassen. Diese Einstellungen im Kernel sind spezifisch für jedes Board in einer Konfigurationsdatei editierbar.

	== Tockloader ==		== Tockloader ==

← Older revision		Revision as of 17:25, 17 October 2022
Line 17:		Line 17:
	Einzigartig an Tock ist auch das Trust-Modell, wie in der Abbildung zu erkennen ist. Grundsätzlich wird nur den Komponenten des Kernels vertraut, jedoch schon nicht mehr den Treibern oder anderer Software, welche mit noch privilegierten Rechten in sog. "Capsules" laufen. Anwendungen wird grundsätzlich nicht vertraut in dieser Architektur. Allgemein kann festgehalten werden, dass das Hail-Board sowie Tock über keine virtuelle Adressierung verfügt, da wir lediglich eine MPU (Memory Proctection Unit) und keine MMU (Memory Management Unit) zur Verfügung haben.		Einzigartig an Tock ist auch das Trust-Modell, wie in der Abbildung zu erkennen ist. Grundsätzlich wird nur den Komponenten des Kernels vertraut, jedoch schon nicht mehr den Treibern oder anderer Software, welche mit noch privilegierten Rechten in sog. "Capsules" laufen. Anwendungen wird grundsätzlich nicht vertraut in dieser Architektur. Allgemein kann festgehalten werden, dass das Hail-Board sowie Tock über keine virtuelle Adressierung verfügt, da wir lediglich eine MPU (Memory Proctection Unit) und keine MMU (Memory Management Unit) zur Verfügung haben.

	Die Architektur von Tock besteht also mehr oder weniger aus 3 Ebenen, wobei der Kernel die erste Ebene bildet. Im Kernel laufen nur die notwendigsten und esszenziellsten Programme, darunter der Scheduler, die boardspezifische Kernel-Konfiguration sowie das HAL (Hardware Abstraction Layer). Jedes Board besitzt seine eigene Kernel-Konfiguration, in der z.B. auch festegelegt wird, wie der Kernel reagieren soll, wenn eine Anwendung oder Capsule abstürzt. Beim Scheduler handelt es sich bei Tock um einen MLFQ-Scheduler (Multi-Level-Feedback-Queue). Außerdem ~~Kernel~~ kann ~~mit~~ sog. "Upcalls" mit den Anwendungen im Userland kommunizieren.		Die Architektur von Tock besteht also mehr oder weniger aus 3 Ebenen, wobei der Kernel die erste Ebene bildet. Im Kernel laufen nur die notwendigsten und esszenziellsten Programme, darunter der Scheduler, die boardspezifische Kernel-Konfiguration sowie das HAL (Hardware Abstraction Layer). Jedes Board besitzt seine eigene Kernel-Konfiguration, in der z.B. auch festegelegt wird, wie der Kernel reagieren soll, wenn eine Anwendung oder Capsule abstürzt. Beim Scheduler handelt es sich bei Tock um einen MLFQ-Scheduler (Multi-Level-Feedback-Queue). Außerdem kann der Kernel durch sog. "Upcalls" mit den Anwendungen im Userland kommunizieren.

	Die zweite Ebene bilden die Capsules, welche zwischen der Anwendungsebene und dem Kernel leben. Die Capsules an sich unterscheiden sich grundsätzlich von Prozessen, da ~~die~~ vollkommen anders vom Kernel und Scheduler behandelt werden. Programme in Capsules laufen im privilegierten Modus, dennoch kommt dies mit einigen wichtigen Restriktionen, welche auch der Programmiersprache Rust zugrunde liegen:		Die zweite Ebene bilden die Capsules, welche zwischen der Anwendungsebene und dem Kernel leben. Die Capsules an sich unterscheiden sich grundsätzlich von Prozessen, da sie vollkommen anders vom Kernel und Scheduler behandelt werden. Programme in Capsules laufen im privilegierten Modus, dennoch kommt dies mit einigen wichtigen Restriktionen, welche auch der Programmiersprache Rust zugrunde liegen:

	* Kooperatives Scheduling: Capsules sind nicht preemptiv durch den Scheduler verwaltbar, sodass dieser stets warten muss, bis die Capsule die Kontrolle zurück ~~gibt~~ an den Kernel, wenn deren Operationen vollständig abgeschlossen sind. Das impliziert aber auch, dass falls die Capsule in eine unendlich Schleife gerät, diese für immer läuft, da der Scheduler wartet, bis die Operationen der Capsule abgeschlossen sind.		* Kooperatives Scheduling: Capsules sind nicht preemptiv durch den Scheduler verwaltbar, sodass dieser stets warten muss, bis die Capsule die Kontrolle zurück an den Kernel gibt, wenn deren Operationen vollständig abgeschlossen sind. Das impliziert aber auch, dass falls die Capsule in eine unendlich Schleife gerät, diese für immer läuft, da der Scheduler wartet, bis die Operationen der Capsule abgeschlossen sind.

	* Keine dynamische Speicherallokierung: Die Speicherallokation für Capsules ist statisch und wird mit dem Systemstart festgelegt. Es ist also nicht ohne weiteres möglich, Speicher für Capsules zu allokieren. Dafür werden sog. "Grants" benötigt, welche im Grunde spezielle Speicherregionen innerhalb des Prozessspeichers sind. Diese werden herangezogen, falls Capsules zusätzlichen Speicher benötigen. Die Entscheidung, dass Capsules nicht dynamisch Speicher allokieren können, ist darauf zurückzuführen, dass dem gesamten System nur wenige Kilobyte an Hauptspeicher zur Verfügung stehen, wodurch es für den Kernel durch dynamische Allokationen schwer ist vorherzusagen, wenn der Hauptspeicher erschöpft ist.		* Keine dynamische Speicherallokierung: Die Speicherallokation für Capsules ist statisch und wird mit dem Systemstart festgelegt. Es ist also nicht ohne weiteres möglich, Speicher für Capsules zu allokieren. Dafür werden sog. "Grants" benötigt, welche im Grunde spezielle Speicherregionen innerhalb des Prozessspeichers sind. Diese werden herangezogen, falls Capsules zusätzlichen Speicher benötigen. Die Entscheidung, dass Capsules nicht dynamisch Speicher allokieren können, ist darauf zurückzuführen, dass dem gesamten System nur wenige Kilobyte an Hauptspeicher zur Verfügung stehen, wodurch es für den Kernel durch dynamische Allokationen schwer ist vorherzusagen, wenn der Hauptspeicher erschöpft ist.

	* Kein Unsafe-Rust: Um Memory-Safety in Capsules zu gewährleisten, werden sich die Eigenschaften von Safe Rust zunutze gemacht. So kann schon zur Compile-Time schon festgestellt werden, ob das Programm Memory-Safety erfüllt. Da Unsafe-Rust ~~verboten~~ ist in ~~Capsules~~, ist es aber auch nicht möglich, bestimme Programme in Capsules zu schreiben, da wir bestimmte Operationen nur mit Unsafe-Rust ausdrücken können. Dennoch benötigen wir durch Safe Rust keine zusätzlichen Mechanismen, um Memory-Safety zu überprüfen an dieser Stelle		* Kein Unsafe-Rust: Um Memory-Safety in Capsules zu gewährleisten, werden sich die Eigenschaften von Safe Rust zunutze gemacht. So kann schon zur Compile-Time schon festgestellt werden, ob das Programm Memory-Safety erfüllt. Da Unsafe-Rust in Capsules nicht erlaubt ist per Konvention, ist es aber auch nicht möglich, bestimme Programme in Capsules zu schreiben, da wir bestimmte Operationen nur mit Unsafe-Rust ausdrücken können. Dennoch benötigen wir durch Safe Rust keine zusätzlichen Mechanismen, um Memory-Safety zu überprüfen an dieser Stelle.

	Zudem kann hier noch erwähnt werden, dass Capsules sich mit dem Kernel einen Stack teilen und auch während der ~~laufzeit~~ nicht änderbar sind. Das führt aber auch dazu, dass wenn eine Capsule ~~crasht~~ bzw. den Kernel-Stack korrumpiert, ~~dieser~~ sich davon nich ohne weiteres ~~recovern~~ kann und ein Neustart des Kernels erforderlich ist. Rust liefert hierbei mit seinen eigenen Sicherheitsgarantien die Memory-Safety der Capsules, sodass es keine fehlerhaften Speicherzugriffe während der Laufzeit gibt.		Zudem kann hier noch erwähnt werden, dass Capsules sich mit dem Kernel einen Stack teilen und auch während der Laufzeit nicht änderbar sind. Das führt aber auch dazu, dass wenn eine Capsule abstürzt bzw. den Kernel-Stack korrumpiert, das System sich davon nich ohne weiteres erholen kann und ein Neustart des Kernels erforderlich ist. Rust liefert hierbei mit seinen eigenen Sicherheitsgarantien die Memory-Safety der Capsules, sodass es keine fehlerhaften Speicherzugriffe während der Laufzeit gibt.


	'''Implementierungen'''		'''Implementierungen'''

	Insbesondere existieren bisher 2 Implementierungen von Bibliotheken, welche eine Schnittstelle für die Anwendungsentwicklung in Tock zur Verfügung stellen. Zum einen die [https://github.com/tock/libtock-c libtock-c], welche C-Bindings bereitstellt und die [https://github.com/tock/libtock-rs libtock-rs], welche direkt Rust-Bindings für die Anwendungentwicklung bereitstellt. Dabei ist die Entwicklung in der libtock-c deutlich weiter vorangeschritten als in der Rust~~-version~~, da dort deutlich mehr Bindings für die Features der Systeme und die des Boards bereitgestellt werden.		Insbesondere existieren bisher 2 Implementierungen von Bibliotheken, welche eine Schnittstelle für die Anwendungsentwicklung in Tock zur Verfügung stellen. Zum einen die [https://github.com/tock/libtock-c libtock-c], welche C-Bindings bereitstellt und die [https://github.com/tock/libtock-rs libtock-rs], welche direkt Rust-Bindings für die Anwendungentwicklung bereitstellt. Dabei ist die Entwicklung in der libtock-c deutlich weiter vorangeschritten als in der in Rust geschriebenen Version, da dort deutlich mehr Bindings für die Features der Systeme und die des Boards bereitgestellt werden.

	Weitere Informationen zu Tock sind in der Dokumentation des [https://github.com/tock/tock Github Repositories von Tock] zu finden.		Weitere Informationen zu Tock sind in der Dokumentation des [https://github.com/tock/tock Github Repositories von Tock] zu finden.
Line 39:		Line 39:
	''' Bootloader '''		''' Bootloader '''

	Zudem ist der Bootloader von Tock ebenfalls in Rust geschrieben, allerdings leider nicht mehr als ~~open~~-~~source~~ verfügbar für das Hail Board. Als [https://github.com/tock/tock-bootloader/tree/master/boards/hail-bootloader Grund] gaben die Entwickler an, dass es sicht vom Aufwand her nicht lohnt, diesen Bootloader zu ~~maintainen~~, da Hail sich auf dem abesteigenden Ast befindet und der Support dafür in Zukunft eingestellt würde. Von daher war es uns nicht möglich, in den Quellcode des Bootloaders zu schauen, der auf diesem Board installiert ist und neue Erkenntnisse dadurch zu gewinnen.		Zudem ist der Bootloader von Tock ebenfalls in Rust geschrieben, allerdings leider nicht mehr als Open-Source verfügbar für das Hail Board. Als [https://github.com/tock/tock-bootloader/tree/master/boards/hail-bootloader Grund] gaben die Entwickler an, dass es sicht vom Aufwand her nicht lohnt, diesen Bootloader zu warten und zu aktualisieren, da Hail sich auf dem abesteigenden Ast befindet und der Support dafür in Zukunft eingestellt würde. Von daher war es uns nicht möglich, in den Quellcode des Bootloaders zu schauen, der auf diesem Board installiert ist und neue Erkenntnisse dadurch zu gewinnen.


	''' Prozesse und Prozessmanagement'''		''' Prozesse und Prozessmanagement'''

	Prozesse erhalten wie in anderen ~~betriebssystemen~~ auch einen eigenen Bereich im Hauptspeicher, welcher in im Falle von Tock in folgende Bereiche eingeteilt ist:		Prozesse erhalten wie in anderen Betriebssystemen auch einen eigenen Bereich im Hauptspeicher, welcher in im Falle von Tock in folgende Bereiche eingeteilt ist:

	* Grant-Segment: Der Prozess kann auf dieses Segment standardmäßig weder lesend noch schreibend zugreifen. Dieses Segment dient dem Kernel zur Speicherverwaltung von den Capsules, kann aber auch asl Buffer für Daten verwendet werden, die der Prozess dann nutzen Kann. In dem Fall ist es dann möglich, über eine <code>allow_readonly()</code> Funktion diese ~~Bereich~~ für den Prozess lesbar zu machen.		* Grant-Segment: Der Prozess kann auf dieses Segment standardmäßig weder lesend noch schreibend zugreifen. Dieses Segment dient dem Kernel zur Speicherverwaltung von den Capsules, kann aber auch asl Buffer für Daten verwendet werden, die der Prozess dann nutzen Kann. In dem Fall ist es dann möglich, über eine <code>allow_readonly()</code> Funktion diese Bereiche für den Prozess lesbar zu machen.

	* Heap-Segment: Das Heap-Segment wird dynamisch allokiert für den Prozess und die Größe dieses Segments wird in der Kernel-Konfikuration spezifisch für jedes Board festgelegt.		* Heap-Segment: Das Heap-Segment wird dynamisch allokiert für den Prozess und die Größe dieses Segments wird in der Kernel-Konfikuration spezifisch für jedes Board festgelegt.
Line 54:		Line 54:
	* Stack-Segment: Die Größe vom Stack wird beim Erstellen des Prozesses final festgelegt und kann dann auch nicht mehr geändert werden. Dazu ist es in Rust-Anwendungen notwendig, diese Stackgröße manuell zu setzen.		* Stack-Segment: Die Größe vom Stack wird beim Erstellen des Prozesses final festgelegt und kann dann auch nicht mehr geändert werden. Dazu ist es in Rust-Anwendungen notwendig, diese Stackgröße manuell zu setzen.

	Dazu gibt es noch das Text-Segment, welches die Anwendung selbst als Binary (TAB) enthält, aber nicht mehr im Hauptspeicher liegt, sondern im Flash-Speicher des Boards. Prozesse werden preemptiv vom Scheduler behandelt, können also während ~~iherer~~ Ausführung durch den Kernel (z.B. aufgrund eines Interrupts) in die Ready-Queue geschoben werden, ~~also~~ muss nicht erst gewartet werden, bis der Prozess die Kontrolle freiwillig wieder abgibt. Da Anwendungen auch in C geschrieben werden können und die Rust-Anwendungen auch Unsafe-Regionen enthalten können, ist es nicht mehr möglich, Memory Safety zur Compile-Time zu garantieren. Daher wird für die Prozesse zur Laufzeit die MPU genutzt, welche überprüft, ob nur gültige Speicherzugriffe und Referenzen genutzt werden. Im Falle eines ungültigen Zugriffs wird ein Fehler geworfen und der Kernel entscheidet, wie mit der Anwendung, die diesen Fehler verursacht hat, verfahren wird.		Dazu gibt es noch das Text-Segment, welches die Anwendung selbst als Binary (TAB) enthält, aber nicht mehr im Hauptspeicher liegt, sondern im Flash-Speicher des Boards. Prozesse werden preemptiv vom Scheduler behandelt, können also während ihrer Ausführung durch den Kernel (z.B. aufgrund eines Interrupts) in die Ready-Queue geschoben werden. Also muss nicht erst gewartet werden, bis der Prozess die Kontrolle freiwillig wieder abgibt. Da Anwendungen auch in C geschrieben werden können und die Rust-Anwendungen auch Unsafe-Regionen enthalten können, ist es nicht mehr möglich, Memory Safety zur Compile-Time zu garantieren. Daher wird für die Prozesse zur Laufzeit die MPU genutzt, welche überprüft, ob nur gültige Speicherzugriffe und Referenzen genutzt werden. Im Falle eines ungültigen Zugriffs wird ein Fehler geworfen und der Kernel entscheidet, wie mit der Anwendung, die diesen Fehler verursacht hat, verfahren wird.

	Findet in einer Anwendung ein fehlerhafter Speicherzugriff statt, der zur Compile-Zeit nicht erkannt wird, so crasht nicht nur die Anwendung selbst. Zusätzlich wird im Kernel von TockOS ~~eine~~ panic ausgelöst, ~~welche~~ den Kernel ebenfalls zum Absturz bringt, sodass danach ein ~~Reset~~ erforderlich ist. Der Kernel entscheidet letztendlich, wie er mit der Applikation verfährt.		Findet in einer Anwendung ein fehlerhafter Speicherzugriff statt, der zur Compile-Zeit nicht erkannt wird, so crasht nicht nur die Anwendung selbst. Zusätzlich wird im Kernel von TockOS ein kritischer Fehler (Rust: panic) ausgelöst, welcher den Kernel ebenfalls zum Absturz bringt, sodass danach ein Neustart erforderlich ist. Der Kernel entscheidet letztendlich, wie er mit der Applikation verfährt.

	Dabei wird nach der Art des Fehlers entschieden, wie der Kernel handelt:		Dabei wird nach der Art des Fehlers entschieden, wie der Kernel handelt:
Line 88:		Line 88:
	</syntaxhighlight>		</syntaxhighlight>

	Aktuell ist im Kernel festgelegt, dass falls Apps abstürzen, dann auch der Kernel durch ein von selbst ausgelöstes PANIC crasht. Damit soll es für die Entwickler einfacher ~~ist~~, die Apps zu debuggen. Daher hier ein Ausschnitt aus dem Kernel, welcher genau diese Fehler erzeugt. Dieser Ausschnitt stammt aus der Kernel-Config und kann manuell angepasst werden.		Aktuell ist im Kernel festgelegt, dass falls Apps abstürzen, dann auch der Kernel durch ein von selbst ausgelöstes PANIC crasht. Damit soll es für die Entwickler einfacher sein, die Apps zu debuggen. Daher hier ein Ausschnitt aus dem Kernel, welcher genau diese Fehler erzeugt. Dieser Ausschnitt stammt aus der Kernel-Config und kann manuell angepasst werden:


Line 99:		Line 99:
	</syntaxhighlight>		</syntaxhighlight>

	Somit wäre es also leicht möglich, dem Kernel andere Handlungsanweisungen zu geben, falls eine App crasht. Aktuell ist der Panic gesetzt, da es sich hierbei um ein Development Board handelt. Es wäre aber auch einach möglich, das falls eine App crasht, der Prozess, in dem die App läuft, zu terminieren und den Kernel ~~einfach~~ weiterlaufen zu lassen. Diese Einstellungen im Kernel sind spezifisch für jedes Board in einer Konfigurationsdatei editierbar.		Somit wäre es also leicht möglich, dem Kernel andere Handlungsanweisungen zu geben, falls eine App crasht. Aktuell ist der Panic gesetzt, da es sich hierbei um ein Development Board handelt. Es wäre aber auch einach möglich, das falls eine App crasht, der Prozess, in dem die App läuft, zu terminieren und den Kernel unbeschadet weiterlaufen zu lassen. Diese Einstellungen im Kernel sind spezifisch für jedes Board in einer Konfigurationsdatei editierbar.

	== Tockloader ==		== Tockloader ==