Eine Systemruf-Schnittstelle dient als Vereinfachung der Benutzung unseres Betriebssystems. Diese Schnittstelle bietet noch keinerlei Schutz. Anwendungen werden nicht dazu gezwungen, ausschließlich über Syscalls mit dem Kern zu interagieren. Im embedded-Bereich ist es durchaus üblich, Syscalls als einfache Funktionsrufe zu implementieren.

Syscalls mit Schutzmechanismen, wie sie bspw. auch in Linux vorkommen, werden in der Nachfolgeveranstaltung Betriebssystemtechnik umgesetzt. Nichtsdestoweniger haben wir einige Kerndatenstrukturen, die wir gern vor dem gleichzeitigen Zugriff mehrerer Kerne oder Aktivitäten schützen würden. Dazu gehören bspw. die Scheduling-Warteschlangen.

Um den Anwendungen dennoch die Features unseres Betriebssystems zur Verfügung zu stellen, ohne Konsistenzprobleme befürchten zu müssen, stellen wir eine Systemruf-Schnittstelle bereit. Die Funktionen des Schedulers bspw. sollen durch den Guarded_Scheduler geschützt werden. Den Anwendungen wird nur ein globales Guarded_Scheduler-Objekt bereit gestellt, nicht jedoch ein Verweis auf das echte Scheduler-Objekt.

Die Auswahl der Objekte und Methoden, die den Anwendungen zur Verfügung stehen soll, muss wohl überlegt sein. Zu wenige Methoden können einschränkend sein, zu viele oder eine falsche Auswahl kann aber gefährlich für das System werden. Welche Funktionalität sollen Anwendungen von unserem Kern verwenden können, welche soll ihnen nicht zur Verfügung stehen dürfen?