A system call interface simplifies the use of our operating system. This interface does not yet offer any protection. Applications are not forced to interact with the kernel exclusively via syscalls. In the embedded area, it is quite common to implement syscalls as simple function calls.

Syscalls with protection mechanisms, such as those found in Linux, are implemented in the follow-up course (Betriebssystemtechnik). Nevertheless, we have some core data structures that we would like to protect from simultaneous access by multiple cores or activities. These include, for example, the scheduling queues.

In order to make the features of our operating system available to the applications without having to worry about consistency problems, we provide a system call interface. The functions of the scheduler, for example, should be protected by the Guarded_Scheduler. Only a global Guarded_Scheduler object is made available to the applications, but not a reference to the real scheduler object.

The selection of objects and methods that should be available to the applications must be carefully considered. Too few methods can be restrictive, but too many or an incorrect selection can be dangerous for the system. Which functionality should applications be able to use from our core, and which should not be available to them?