How is Operating System Code Structured?

Operating systems have two common structures.

Monolithic O/S

Here the O/S consists of one big set of routines that perform all O/S functionality. Subroutines are invoked to provide O/S services, and call one another in the performance of these services. Applications execute as separate processes.

In this approach some order can be attained by layering the software. This is a technique common in many complex applications (communication protocols for example). In this case,

• the hardware is the lowest layer
• the top layer is the user interface
• each layer can use the services of the the layers below, but cannot use the services of any of the above layers.
• each successive layer adds functionality and increases abstraction

This allows for:

1. easier understanding and maintenance of the code
2. independent testing as the individual layers are implemented

It essentially brings some order to an otherwise terribly complex piece of code.

Kernel Approach

Here - the monolithic O/S is trimmed down so that the core set of routines handle only the most basic set of O/S functions such as process creation, process destruction, communication, and maybe a bit more. This leaner O/S is now called the kernel. The rest of the operating system functionality is implemented by special processes called system processes (which are part of the O/S - they are not applications).

This keeps the kernel simple. Processes are modular and can be added to, replaced, debuged and maintained much more easily. They can possibly even be added at runtime - imagine adding a function to an operating system without even rebooting it, let alone recompiling it.

This structure does, however require the designer to give extra thought to how hardware devices are handled. You can give this more thought when we talk about interrupts and ISRs.