Operating System Software Architecture

Software Architecture is one of the last understood concepts in computer science. Architecure, as generally defined, goes mostly unquestioned on our minds and is bound to the design of buildings and other physical structures. When brought in context for hardware, Computer Architecture still goes easily on most of us. However, when the subject approaches software, the concept of Software Architecture often goes too abstract on an already abstract world.

Perhaps no one has reasoned on Operating System Software Architecture as deeply as Prof. Schröder-Preikschat. On his book The Logical Design of Parallel Operating Systems and on a series of publications afterwards, he emphatically makes the point on the separation of structural and behavioral properties of operating systems, showing that the same behavior---and indeed the same source code---can be brought about on a variety of architectures. In other words, an operating system can deliver its functionality taking the software architecture that better matches the requirements of the applications running on top of it.

The most known operating system architectures are:

Besides these architectures, EPOS features a built-in architecture that consists basically in separating OS code from application code without installing a system call interface. It is a mostly uninteresting architecture, but it is quite useful in two development scenarios:

  1. Application debugging: even if a system is conceived as single-task, application development is likely to incur in errors that escape from application into the OS (library code). By activating a MMU and marking OS memory as protected, one can more easily catch such bugs (since they will now cause traps that can precisely report the problem when and where it happened).

  2. OS development: sometimes developing new OS functionality on a library-based architecture can be quite convenient in terms of compilation time.

To do

On your path to make OpenEPOS a real microkernel, the built-in architecture will be very handy. It will enable you to isolate the OS from the application without raising a trap on each small step. The techniques explored while solving the multiple, specialized heaps exercise will also be very helpful here, since isolating application and OS heaps can be achieved using them.

Implement the built-in architecture and ensure both code and data from the operating system, even dynamically allocated data, go to the highest addresses, while application's go to the lowest. Traces will be fundamental to demonstrate such an isolation, and the final mapping of OS memory as supervisor mode will confirm it.