Operating Systems

Structure of an Operating System

An operating system is composed of a kernel, possibly some servers, and posssibly some user-level libraries. The kernel provides operating system services through a set of procedures, which may be invoked by user processes through system calls. System calls look like procedure calls when they appear in a program, but transfer control to the kernel when they are invoked at run time. ( read is an example of a system call in Unix.)

In some operating systems, the kernel and user-processes run in a single (physical or virtual) address space. In these systems, a system call is simply a procedure call. In more robust systems, the kernel runs in its own address space and in a special privileged mode in which it can execute instructions not available to ordinary user processes. In such systems, a system call invokes a trap as discussed below.

A trap is a hardware event that invokes a trap handler in the kernel. The trap indicates, in appropriate hardware status fields, the kind of trap. Traps may be generated implicitly by the hardware to signal events such as division by zero and address faults (which we will discuss later), or explicitly by a process when it executes a special instruction. Explicit or user-initiated traps are used to handle system calls. A system call stores the name of the call and its arguments on the stack and generates a user-initiated trap. The trap handler in the kernel knows, from the type of the trap, that it is a user-initiated trap asking for a system call, finds the name of the systems call, and calls the appropriate kernel procedure to handle the call passing it the arguments stored on the stack.

We will later consider the various techniques for structuring the kernel. As we shall see, kernels may be layered, object-oriented, or decomposed into kernel processes.

Not all operating services have to be provided by the kernel. Modern operating systems also define servers, which are user processes that offer operating system services to other processes. These services are invoked by clients through interprocess communication (IPC) primitives. We shall see later the rationale for transferring functionality from the kernel to servers. We shall also see the minimum functionality that needs to be supported in the kernel. In micorkernel-based systems, the kernel provides this minimum functionality.

The cost of invoking system calls and IPC primitives is more than the cost of invoking a simple procedure call when multiple address spaces are supported by the system. Therefore, as we shall see later, some of the traditional OS functionality is sometimes also provided by user-level libraries.

Multitasking, preemptive, re-entrant kernel

* Supports implementing real-time applications as multiple semi-autonomous tasks. Tasks are always in one of five states: running, ready, blocked, suspended, or delayed.

* Provides for task communication and synchronization, both with other tasks and with interrupt service routines.

Priority Based

* Tasks are implemented as light-weight threads assigned a priority at time of creation.

* Task priorities can be dynamically changed with OsSetTaskPri(). The new priority takes effect immediately. Tasks pending in a priority queue are dynamically re-ordered in the queue.

* A task's priority is temporarily boosted when holding ownership of a mutex being requested by a higher priority task (priority inheritance).

Task Synchronization and Communication

* Semaphores and queues perform either priority or FIFO scheduling of pending tasks. Semaphores are counting semaphores. Message queues have either a fixed maximum size or grow freely, limited only by the amount of available memory.

* Mutexes operate like binary semaphores with ownership and priority inheritance to avoid the problem of priority inversion.

* Events can make multiple tasks ready with a single system call. Events are posted to a nexus which may contain any number of blocked tasks. Tasks waiting for an event use a 32-bit mask to select which events they respond to.

* Timers can be used in a wide variety of system calls. Semaphores, messages, and events can be posted after a fixed delay or posted repeatedly at fixed intervals. Application functions can be called after a fixed delay, or called repeatedly at fixed intervals. Timers can be stopped, tested for expiration, and/or deleted at any time.

Deterministic

* Interrupt latency does not increase as the number of tasks, semaphores, queues, etc., increase.

* The execution time of every service call is independent of the number of tasks, queues, semaphores, etc., in the system, except for the delete and get identifier calls which are infrequent operations.

Responsive

* Timer-related processing that is variant, such as sorting the timer queue, is performed in the background using kernel tasks. Minimal work is performed up front when a system call requires timer processing, allowing the CPU to return more quickly to the application.

Flexible Scheduler

* The scheduler can be configured as non-preemptive, a requirement for some third-party communication protocol stacks. When non-preemptive, running tasks always keep the CPU until making a service call that blocks.

* If configured as preemptive, the scheduler always runs the highest priority ready task. The running task is preempted whenever an interrupt makes ready a task with higher priority than the currently running task.

* Preemption can be temporarily disabled with OsLockTask(). Preemption is re-enabled by either calling OsUnlockTask(), or by making a service call that blocks.

* Tasks may be configured for round robin scheduling among tasks of the same priority. The time slice value is configurable and may be examined or modified at any time.

Easy to Use

* A compile-time option promotes all service call errors to fatal errors that cause an error message on stderr and a break into the debug monitor. This helps catch simple programming errors that can otherwise waste valuable time.

* Kernel objects (tasks, semaphores, queues, mutexes, nexuses, timers) are created dynamically upon request by the application. There is no configuration file to edit and maintain as the application grows. The only limit is the amount of available memory.

Interrupt Service Routine Manager

* isrCreate() creates an entry in the CPU's vector table and installs "wrapper" routines that save and restore the minimal registers required to allow the service routine to be written in C.

* The CPU vector table is initialized at startup with default vectors that allow bus errors and spurious interrupts to be reported on the stderr console.

Command Line Debug Monitor

* Displays the percent of CPU time used by each task and ISR. Displays the stack low water mark for each task. Displays a log of past system calls including the time of the call, the name of the task or ISR making the call, and the values of the parameters used. Allows interactive querying of the state of each task, semaphore, etc.

* Application programs, device drivers, etc. can extend the monitor by adding name strings and code for additional commands.

Integrated Development Environment

* Integrated with TargetToolsâ„¢, the IDE for embedded development from Blunk Microsystems with an integrated compiler and kernel-aware debugger, visual code editor, search and replace tool, BDM for board bring-up, and fast Ethernet download.

Turnkey Solution

* Provided with source code, default compiler settings, linker command files, project files, and a re-entrant Standard C runtime library.

* Blunk Microsystems provides board support packages for a range of commercial CPU boards and provides competitive bids on board support packages for custom designs.

Royalty Free

* Includes source code, User's manual, sample applications, and one year of technical support.

This is impossible to answer conclusively. In addition to the fact that no operating system is perfectly suited to all tasks, the word free itself is up for debate.

Free can have several different meanings to different people. To many people it means that it is free of any monetary cost. To others, free means that something lacks any restrictions on what you can or cannot do with it.

In operating systems, an operating system that restricts what you can do with it (such as modify the code or sell it) is considered proprietary. The only free operating systems that do not impair your rights to sell or modify them. Even within free systems, there is debate. Systems under licenses like the GPL force you to make any changes you make to a program you release to the public freely available. Other licenses like the BSD or MIT license allow you to keep the changes you make proprietary, and even re-license under a different license without making the source available.

The operating systems that are considered the best in their field are listed below. More than one will still need to be listed, as there are still things about them that would make them unsuitable for a large number of people.

MorphOS - MorphOS is a desktop operating system with a multimedia-oriented operating system modeled after AmigaOS. Limitations: available only for workstations with PowerPC processors. Limited selection of applications. No memory protection.

BeOS - Multimedia desktop with many features considered rather advanced in its time. Fast microkernel design. Interface is considered by most to be very easy to learn. Decent homebrew community. Limitations: Company went out of business. Limited selection of apps. Often does not work on computers newer than 2004.

QNX - Fast and responsive on extremely low-end / older hardware. Highly reliable and compact. Applications from many other systems like Linux are easily ported to it. Limitations: designed for embedded use, not desktop. Lacks many basic desktop features for above reason. Installation requires (free) registration at comapny's website. Commercial use would require purchase of a (very expensive) license.

DR-DOS - 100% compatible MS-DOS clone. Includes many features that MS-DOS didn't support. Limitations: does not come with a graphical user interface. Only capable of single-tasking without some complex TSRs. Limited support for modern hardware.

QNX - POSIX-compliant; highly secure. Many web server packages have already been ported to it. Limitations: commercial use would require purchase of a (very expensive) license.

QNX - realtime, portable, highly reliable. Limitations: commercial use requires purchase of a (very expensive) license.

Linux - Large selection of applications. Support for a broad range of hardware, and runs on systems both old and new. Highly reliable and secure. Growing community focusing on increasing ease of use. Limitations: Limited selection of commercial software. The large number of choices in distros and desktop environments can be daunting. Some devices do not work in Linux, simply because the vendors will not release hardware specifications.

FreeBSD - large selection of software (pretty much whatever runs on Linux). Less restrictive licensing (BSD). About 95% of hardware supported in Linux is supported by FreeBSD. Highly secure and reliable. Limitations: awkward installation of programs (except PC-BSD variant). Limited selection of commercial software. Community is highly devisive and prone to fragmentation. Some hardware devices do not work in FreeBSD due to lack of hardware documentation.

Linux - reliable and secure. Very large support for commercial server software. Scales well across multiple cores and handles multi-threading well. Limitations: no support for some proprietary Microsoft extensions (like ASP).

FreeBSD - highly reliable and secure. Very large selection of commercial server software. Decent performance and hardware scaling. Limitations: no support for some proprietary Microsoft extensions. No major commercial backers.

Linux - excellent documentation and reliability. Easily portable. Highly modular (can have unneeded components removed). Limitations: size still cannot be reduced enough for some types of devices.

eCos - designed from groun up for emdedded use. Highly portable and POSIX compliant. Limitations: ?