We argue that the first-level interrupt handler is also required to act in the kernel,
as the hardware typically switches into a privileged processor mode in case of an
interrupt.
For a fault-tolerant safety-critical operating system, GAFT is also part of the
runtime system, as already shown in Chap. 4. Specifically, the tasks fault detection,
system reconfiguration, preparation for recovery, and recovery become essential
parts of the runtime system. In this chapter, we focus on the task preparation for
recovery.
• We divide possible operating system architectures into three classes: Simple
unified memory architectures, microkernels, and monolithic kernels.
• Microkernel operating systems such as L4 [1] implement only the three classical
mechanisms in the runtime system itself and move everything else out of the
kernel, with the advantage that a failed software component be it a program or a
driver, does not influence the runtime system stability by design.
Unfortunately, the message-passing mechanism that is required by such systems
had in earlier times significant negative influence on the performance as many task
switches are required by such a system [1]. However, in recent developments, the
overhead could be lowered [3, 4] but is still significant.
Monolithic kernels such as Linux or Windows integrate the three low-level tasks
including all drivers in kernel space. Therefore, even a third-party driver can, in
these operating systems, corrupt the whole kernel space and lead to fatal crashes.
More than 80% of all Windows XP blue screens (traps) are caused by driver errors.
However, less context switches are required in such an operating system in
comparison to the microkernel approach, and thus a general improved performance
is observable. Applications usually run in distinct memory areas, i.e., they are
isolated from each other, but have the kernel mapped in the address space, protected
by the memory management unit (MMU).
Simple unified memory architectures use one memory space for runtime system,
applications, and data. Their big advantage is their simplicity, i.e., they are easily
understandable and manageable. Clear interfaces between parts of this architecture
with reduced number of waiting states in the scheme of interaction enable performance gain that is unachievable on complex instruction computer systems (CICS).
Another advantage of RISC and simple unified memory architectures is the ability
to execute fix time instructions useful especially in real-time applications.
Arguments pros and cons about RISC and CISC architectures are not a subject of
this research, comprehensive analysis of these architectures might be found in [5],
and nothing new was discovered since then.
We do not discuss or consider her any applications based or design done using
Java due to limitations of them for real-time applications. In spite of further analysis
of language properties based on Oberon and Oberon-like languages [4, 6–13], we
do not consider application protection.
It is obvious that the first two approaches need a sophisticated MMU to support
flexible memory partitioning and are not suited for fairly simple systems.
112
8 Recovery Preparation
as the hardware typically switches into a privileged processor mode in case of an
interrupt.
For a fault-tolerant safety-critical operating system, GAFT is also part of the
runtime system, as already shown in Chap. 4. Specifically, the tasks fault detection,
system reconfiguration, preparation for recovery, and recovery become essential
parts of the runtime system. In this chapter, we focus on the task preparation for
recovery.
• We divide possible operating system architectures into three classes: Simple
unified memory architectures, microkernels, and monolithic kernels.
• Microkernel operating systems such as L4 [1] implement only the three classical
mechanisms in the runtime system itself and move everything else out of the
kernel, with the advantage that a failed software component be it a program or a
driver, does not influence the runtime system stability by design.
Unfortunately, the message-passing mechanism that is required by such systems
had in earlier times significant negative influence on the performance as many task
switches are required by such a system [1]. However, in recent developments, the
overhead could be lowered [3, 4] but is still significant.
Monolithic kernels such as Linux or Windows integrate the three low-level tasks
including all drivers in kernel space. Therefore, even a third-party driver can, in
these operating systems, corrupt the whole kernel space and lead to fatal crashes.
More than 80% of all Windows XP blue screens (traps) are caused by driver errors.
However, less context switches are required in such an operating system in
comparison to the microkernel approach, and thus a general improved performance
is observable. Applications usually run in distinct memory areas, i.e., they are
isolated from each other, but have the kernel mapped in the address space, protected
by the memory management unit (MMU).
Simple unified memory architectures use one memory space for runtime system,
applications, and data. Their big advantage is their simplicity, i.e., they are easily
understandable and manageable. Clear interfaces between parts of this architecture
with reduced number of waiting states in the scheme of interaction enable performance gain that is unachievable on complex instruction computer systems (CICS).
Another advantage of RISC and simple unified memory architectures is the ability
to execute fix time instructions useful especially in real-time applications.
Arguments pros and cons about RISC and CISC architectures are not a subject of
this research, comprehensive analysis of these architectures might be found in [5],
and nothing new was discovered since then.
We do not discuss or consider her any applications based or design done using
Java due to limitations of them for real-time applications. In spite of further analysis
of language properties based on Oberon and Oberon-like languages [4, 6–13], we
do not consider application protection.
It is obvious that the first two approaches need a sophisticated MMU to support
flexible memory partitioning and are not suited for fairly simple systems.
112
8 Recovery Preparation