Kernel Design
The OS is a monolithic kernel designed for use on fairly modern Cortex-based microcontrollers. In order to make development easier than traditional embedded programming, user programs are separated from the kernel source tree, and the kernel aims at providing a POSIX compatible interface.
Proper system calls are used to provide the barrier between userspace and kernelspace, which also provides a clear definition of what the user program can and can not do with the kernel. These provide a solid foundation for later expansions and features.
The Virtual File System provides a single unified interface to all kinds of services, such as device drivers and files on different storage media using different file systems.
Component Overview
The simplified figure above illustrates how the main components of the operating system fit together. The blue user software component is the only component that always runs in an unprivileged state. All other components run in privileged state and has access to all memory and hardware resources, however only the purple components access the underlying hardware. These components are also called architecture dependent components as they change with the underlying hardware.
The yellow component is the third-party FAT file system driver. Its code is in
the kmod
repository group as it is a kernel module, and compiled separately.
Crash Handling
Crashes detected in user software causes the offending program to be terminated, while all other software continues to run as normal. This is possible because of the Memory Protection Unit present in the CPU. The MPU prevents one process from directly modifying another, and so it is reasonable to assume that a recovery is possible.
The kernel automatically frees any resources used by the crashed program and notifies the owner that started it, which is expected to handle the absence of that program. If the root program has crashed or terminated (the program started by init at boot time), the init process restarts it automatically.
Crashes detected in the kernel is always assumed to be fatal as there is no
guarantee that any other component will continue to be stable. If the crash
was detected by a manual check and the Panic
function was called the
specified error message will be displayed. Other errors will trigger a core
dump, allowing a programmer to find the location and cause of the error.
Since microcontroller systems are normally independent it is suggested that a hardware watchdog is used. This watchdog should be accessible through a device driver and reset periodically by the top-level user software. This way an unhandled error will always cause a reset after a set interval.