In the context of safety-critical systems, where no faults at all can be tolerated, it
is critical to eliminate all possible sources of failures and thus the additional
overhead of the microkernel approach can happily be traded against higher reliability. All subsystems, such as hardware drivers, network stack, and file systems,
should be moved out of the kernel so that faults cannot spread in the system
(Fig. 8.1).
If the hardware platform provides a memory management unit (MMU), this unit
is used to implement process isolation either by having a distinct address space per
process or by having one shared address space and a capabilities mechanism [14].
If the platform does not have a memory management unit, the process isolation
relies solely on the programming language. It is possible to structure the language
in such a way that processes can only access their own modules and therefore not
unintentionally interfere with others. In addition, this clear separation allows simplified process recovery, as the assigned memory space can simply be erased and
the process restarted.
If the programming language does not provide any means to implement process
isolation, a strict coding policy could be used instead. It is then up to the responsibility of the programmer to implement proper isolation, which is unfortunately
error-prone and therefore not practical.
In our case, the anticipated ERRIC hardware platform does not support virtual
memory, which means that one large address space for all applications is used and
the language is responsible for implementing the isolation. As long as the memory
is not corrupt, this is perfectly sufficient, but in case of memory corruption,
Fig. 8.1 Monolithic kernel versus microkernel
8.1 Runtime System Support for Fault Tolerance and Reconfigurability
113
is critical to eliminate all possible sources of failures and thus the additional
overhead of the microkernel approach can happily be traded against higher reliability. All subsystems, such as hardware drivers, network stack, and file systems,
should be moved out of the kernel so that faults cannot spread in the system
(Fig. 8.1).
If the hardware platform provides a memory management unit (MMU), this unit
is used to implement process isolation either by having a distinct address space per
process or by having one shared address space and a capabilities mechanism [14].
If the platform does not have a memory management unit, the process isolation
relies solely on the programming language. It is possible to structure the language
in such a way that processes can only access their own modules and therefore not
unintentionally interfere with others. In addition, this clear separation allows simplified process recovery, as the assigned memory space can simply be erased and
the process restarted.
If the programming language does not provide any means to implement process
isolation, a strict coding policy could be used instead. It is then up to the responsibility of the programmer to implement proper isolation, which is unfortunately
error-prone and therefore not practical.
In our case, the anticipated ERRIC hardware platform does not support virtual
memory, which means that one large address space for all applications is used and
the language is responsible for implementing the isolation. As long as the memory
is not corrupt, this is perfectly sufficient, but in case of memory corruption,
Fig. 8.1 Monolithic kernel versus microkernel
8.1 Runtime System Support for Fault Tolerance and Reconfigurability
113