test

ChorusOS 5.0 Features and Architecture Overview

Chapter 2 Architecture and Benefits of the ChorusOS Operating System

This chapter describes the general architecture and the benefits provided by the ChorusOS operating system.

General Architecture

The architecture of the ChorusOS operating system is divided into layers built one on top of the other, as illustrated in the following figure.

Figure 2-1 The Layered Architecture of the ChorusOS Operating System

Graphic

The following sections provide descriptions of the key components and main advantages of the ChorusOS operating system.

Multi-Platform Development Environment

The Sun Embedded Workshop software, the ChorusOS operating system development environment, provides the tools and libraries for developing C and C++ applications on a range of supported platforms. Development takes place on one system, the host (UltraSPARC), and the operating system is deployed on one or more supported reference target boards.

The ChorusOS operating system also provides several utilities for managing the operating system and applications running on the target. These utilities include components that can be added to the operating system configuration.

The development environment includes:

C & C++ Development Toolchain:

GNU gcc and g++ cross-compilers.

C & C++ Symbolic Debugger:

GNU GDB debugger for the ChorusOS operating system allows you to see what is going on inside an application while it executes or what an application was doing at the moment it crashed. The GDB Debugger offers the following features:

  • Easy-to-use graphical user interface (GUI)

  • Support for debugging several applications running on multiple targets with different processor architectures

  • Debugging of multithreaded user and supervisor applications, including relocatable applications

  • Flexible thread handling: one window per thread, breakpoint per thread or per application

  • Visualization of ChorusOS abstractions related to debugged applications or global to the system

  • Application debug over Ethernet or serial line, and system debug over serial line

  • Ability to debug almost every piece of code, including the boot process, the C_OS, the drivers and the applications

An Embedded Debugger:

Which provides symbolic debugging for all system applications and can be called automatically in the case of unrecoverable error.

Configuration Tools:

The ChorusOS operating system is configured simply by providing a list of the required components. The configuration tools provided, as part of the Sun Embedded Workshop software, manage any hidden dependencies or possible incompatibilities.

The configuration tools are designed to be flexible enough to be extended to configure any other system component (OS or drivers) or even application actors that are part of the ChorusOS operating system image.

You can use either the graphical interface, called Ews, or a command-line interface to view and modify the characteristics of a ChorusOS operating system image. In addition to the possibility of selecting only the required components for the operating system, the Sun Embedded Workshop software supports three other levels of system configuration:

Resources

For the list of components selected, it is possible to fix the amount of resources to be managed, and to set the value of tunable parameters; for example, the amount of memory reserved for network buffers.

Boot Actors

It is possible to include additional actors in the system image loaded at boot time.

Environment

System-wide configuration parameters can be fixed by setting UNIX-like environment strings that the operating system and actors retrieve upon initialization; for example, an IP address can be defined globally by setting LOCAL_INADDR="192.33.15.18" using the configuration tool.

A set of Libraries:

  • Thread-safe C++

  • ANSI-C (POSIX 1003.1 compliant)

  • POSIX 1003.1 timers, message queues, shared memory, and semaphores

  • POSIX 1003.1 pthreads

  • POSIX 1003.1g sockets

  • BSD File I/O

  • Thread-safe mathematical ANSI-C

  • Mathematical IEEE-754

  • Library resolve for DNS/NIS client access

  • C++ iostream

  • C++ exceptions

  • C++ STL Management of per-thread private data

  • LDAP

  • Sun RPC

  • X11, Xaw, Xext, Xmu, and Xt libraries

The Sun Embedded Workshop software also provides several utilities for managing the operating system and applications running on the target. These utilities include components that you can add to the operating system configuration.

The application management utilities include:

Netboot:

Used to boot the ChorusOS operating system remotely using TFTP, when the target does not provide an embedded boot facility

Default Console:

Used to direct all console I/O to a local display or to a remote host via a serial line

Remote Shell (rsh):

Used to execute commands remotely on the target from the host; in particular, this feature allows applications to be loaded dynamically

Resource Status:

Used to list the current status of all operating system resources. For example, actors, threads, and memory.

Logging (LOG):

Used to log operating system events as they occur on the target

Monitoring (MON):

Used to monitor operating system objects, so that user-defined routines are called when certain operations are performed on specified objects

Profiling:

Used to run profiling sessions on system applications

Benchmarking (PERF):

Used to benchmark the operating system

ChorusOS-Solaris Convergence

The ChorusOS operating system is the real-time embedded operating system companion to the Solaris operating environment, providing the following advantages:

Design flexibility

The sharing between the two operating systems means developers can decide exactly how much of their solution will use the Solaris environment, and how much will be based on the ChorusOS operating system, but use all the same surrounding technology.

Gradual migration

By making it easy for developers to choose any percentage split between the ChorusOS operating system and the Solaris operating system, and by making all the surrounding modules and technologies converge with both, Sun enables developers and their operator clients to begin at any point in the evolution from real-time embedded to computer-based systems, and migrate slowly to where they want to go as they replace obsolete systems and invest in new technologies.

Portable Binary System

For each supported target processor family, the ChorusOS operating system comes with the implementation of at least one reference target board and provides a complete set of well-defined interfaces allowing you to port the ChorusOS operating system to other reference boards in the same target family. The Boot Kernel Interface (BKI) and Device Driver Interface (DDI) available in the binary release of ChorusOS allow you to customize the boot method and to add new drivers.

Configurability

The ChorusOS operating system uses a flexible, component-based architecture that allows different services to be configured into the runtime instance of the ChorusOS operating system. This allows the runtime instance of the ChorusOS operating system to be finely tuned according to the underlying hardware platform, the memory footprint requirements, and the application features.

Essential services required to support real-time applications running on the target system are provided by the core executive, and each optional feature of the operating system is implemented as a separate runtime component that can be added to, or removed from the operating system, as required. This means that the operating system can be configured very accurately to meet the exact needs of a given application or environment, saving on memory and improving performance. Additional components can be added, to create a tailor-made instance, to the level of the resources available.

The core executive can support multiple, independent applications running in both user and supervisor memory space. The core executive can be complemented with additional components to add the features required to support a given application. Additional components supplied by the Sun Embedded Workshop software include:

This flexible architecture is shown in Figure 2-2.

Figure 2-2 The ChorusOS Component-based Architecture

Graphic

Detailed descriptions of the optional features for the ChorusOS operating system are provided in the ChorusOS 5.0 Application Developer's Guide.

By taking advantage of the component-based architecture, the application developer can choose between an extremely small operating system that offers simple scheduling and memory options, or a fully-featured, multi-API software platform.

As well as making it possible to produce multiple versions of the operating system, each of which is optimized for its own environment, the component-based architecture provides the following additional benefits:

Configuration Profiles

The ChorusOS operating system provides two standard configuration profiles. These serve as starting points for defining your own configuration:

Basic Profile

The basic profile is an example of a small deployment system and defines a realistic configuration while keeping the footprint as small as possible. When using the basic profile, all applications are usually embedded in the system image and launched either at boot time as boot applications, or subsequently from the file system.

Extended Profile

The extended profile is an example of a development system and should be viewed as a reference configuration for telecommunications systems. It includes support for networking using remote Inter-Process Communication (IPC) over Ethernet and a Network File System (NFS) client, using the protected memory model. It allows the development and loading of multi-actor applications. These actors may use any ChorusOS API, provided that the corresponding feature is part of the system configuration.

System Image

Optional features are implemented as components that can be added to, or removed from, an instance of the ChorusOS operating system, known as the system image. The system image is made up of binary or executable files that define the operating system and initial application processes. Once you have built your system image, you are ready to start using the ChorusOS operating system. In this way, the operating system can be very finely tuned to meet the requirements of a given application or environment. The core executive component must always be present in a ChorusOS system image.

Each API function in the ChorusOS operating system is contained in one or more of the configurable components. As long as at least one of these components is configured into a given system image, the function is available to be called. Some library functions are independent of any specific component and are always available.

APIs in the ChorusOS Operating System

The ChorusOS operating system offers three sets of application programming interfaces, including POSIX API compatibility. Each set is intended to serve a certain class of applications.

POSIX Processes

These applications have access to a fully POSIX-compliant API for process management, signals, threads, input/output, memory management, thread sysnchronization, and timing services. This greatly extends the functionality of the ChorusOS operating system, at the same time as allowing easier migration to applications developed by the user, and closer conformity with the Solaris operating environment.

These applications also have access to APIs developed for the ChorusOS services (non existent in POSIX) that conform to the POSIX style, such as system events, black box, watchdog, IPC, and MIPC.

ChorusOS Actors

These include ChorusOS microkernel actors that run the system and the drivers. These applications have access to APIs for all ChorusOS microkernel services.

ChorusOS 4.x Legacy applications

An API developed for release 4.x of the ChorusOS operating system, to support applications developed with POSIX-like functionality without being fully POSIX-compliant. Now superseded by the full POSIX implementation described above, but retained for reasons of backward compatibility.

Caution - Caution -

The POSIX processes and the ChorusOS actors combine to provide a rich range of functionality. However, the two APIs are mutually exclusive. For details of the implementations of these APIs in release 5.0 of the ChorusOS operating system, see API(5FEA).

Microkernel

The microkernel is the heart of the ChorusOS operating system and contains the minimum elements required to make a functioning system. In addition to the optional components you can configure into your ChorusOS operating system, the microkernel contains the kern, private data manager (pd), persistent memory manager (pmm), and core executive components. The kern, pmm, and pd provide a minimum set of interfaces that are used by the remainder of the operating system:

The services provided by the core executive are explained below.

Core Executive

The essential services required to support real-time applications are provided by the core executive. The core executive can support multiple, multithreaded applications running in both user and supervisor memory space.

The core executive implements the basic ChorusOS execution model and provides the framework for all other configurable features. Every system image must include the core executive.

The core executive provides the following functionality:

No synchronization, scheduling, time, communication or memory management policies are wired into the core executive. These policies and services are provided by additional features, that the user selects depending on the particular hardware and software requirements.

Actors

This section provides an introduction to actors in the ChorusOS operating system. For further information regarding topics such as loading actors, spawning actors, and their execution environment and communications, see the ChorusOS 5.0 Application Developer's Guide.

Actor Definition

An actor is the unit of loading for an application. It serves also as the encapsulation unit to associate all system resources used by the application and the threads running within the actor. Threads, memory regions and communication end points are some examples of these resources. These are covered in detail in the ChorusOS 5.0 Application Developer's Guide. All system resources used by an actor are freed upon actor termination.

Some resources, known as anonymous resources, are not bound to a given actor. These must be freed explicitly when they are no longer required. Examples of anonymous resources are physical memory, reserved ranges of virtual memory, and interrupt vectors.

The ChorusOS operating system is dedicated to the development and execution of applications in a host-target environment where applications are developed, compiled, linked, and stored on a host system and then executed on a reference target board where the ChorusOS operating system is running. When configured correctly, the ChorusOS operating system offers convenient support for writing and running distributed applications.

Within the ChorusOS operating system environment, an application is a program or a set of programs, usually written in C or C++. In order to run, an application must be loaded on the ChorusOS runtime system. The normal unit of loading is called an actor and is loaded from a binary file located on the host machine. As with any program written in C or C++, an actor has a standard entry point:

int main()
 {
 /* A rather familiar starting point, isn't it? */
 }

The code of this type of application will be executed by a main thread that is created automatically by the system at load time. The ChorusOS operating system provides means to create and run more than one thread dynamically in an actor. It also offers services that enable these actors, whether single-threaded or multi-threaded, to cooperate, synchronize, locally or remotely exchange data, or get control of hardware events, for example. These topics are covered step-by-step in the ChorusOS 5.0 Application Developer's Guide.

An actor can be of two types: either a supervisor actor or a user actor. These types define the nature of the actor address space. User actors have separate and protected address spaces so that they cannot overwrite each other's address spaces. Supervisor actors use a common but partitioned address space. Depending on the underlying hardware, a supervisor actor can execute privileged hardware instructions, such as initiating an I/O, while a user actor cannot. See "User and Supervisor Actors".

Note -

In flat memory, supervisor and user actors share the same address space and there is no address protection mechanism.

Binary files from which actors are loaded can also be of two types: either absolute or relocatable. An absolute binary is a binary where all addresses have been resolved and computed from a well-known and fixed basis that cannot be changed. A relocatable file is a binary that can be loaded or relocated at any address.

Both user and supervisor actors can be loaded either from absolute or relocatable binary files. However, common practice is to load them from relocatable files to avoid a static partitioning of the common supervisor address space, and to allow the loading of user actors into this space in the flat memory model. This is covered in detail in "User and Supervisor Actors".

Naming Actors

Every actor, whether it is a boot actor or a dynamically-loaded actor, is uniquely identified by an actor capability. When several ChorusOS operating systems are cooperating together over a network in a distributed system, these capabilities are always unique through space and time. An actor may identify itself with a predefined capability, for example:

K_MYACTOR.

In addition, an actor created from the POSIX personality is identified by a local process identifier.


host% rsh target hello
Started pid = 13
host%

Where target is the name of your target.

User and Supervisor Actors

There are two main kinds of actor run within the ChorusOS operating system environment: user actors and supervisor actors.

A user actor runs in its own private address space so that if it attempts to reference a memory address that is not valid in its address space, it encounters a fault and, by default, is automatically deleted by the ChorusOS operating system.

Supervisor actors do not have their own fully-contained private address space. Instead, they share a common supervisor address space, which means that an ill-behaved supervisor actor can access, and potentially corrupt, memory belonging to another supervisor actor. The common supervisor address space is partitioned between the ChorusOS operating system components and all supervisor actors.

As supervisor actors reside in the same address space, there is no memory context switch to perform when execution switches from one supervisor actor to another. Thus, supervisor actors provide a trade-off between protection and performance. Moreover, they allow execution of privileged hardware instructions and so enable device drivers, for example, to be loaded and run as supervisor actors.

On most platforms, the address space is split into two ranges: one reserved for user actors and one for supervisor actors (see Figure 2-3). As user actor address spaces are independent and overlap each other, the address where these actors run is usually the same, even if the actors are loaded from relocatable binaries. On the other hand, available address ranges in supervisor address space may vary depending on how many and which supervisor actors are currently running. Since the ChorusOS operating system is able to find a slot dynamically within the supervisor address space to load an actor, the user does not need to be aware of the partitioning of the supervisor address space: using relocatable binary files is sufficient.

Figure 2-3 User and Supervisor Address Spaces

Graphic

In addition to being either a user or supervisor actor, an actor can be trusted, which gives it the right to call certain privileged system services. Trusted actors are also referred to as system actors. A supervisor actor is by definition trusted.

Inter-Actor Communication

The ChorusOS operating system offers a set of services for communicating between actors. Two actors can be made to communicate by sharing memory. Other communication mechanisms can be split into two categories:

Threads

This section provides an overview of the use of threads in the ChorusOS operating system. For further information regarding threads, thread handling, thread synchronization, thread scheduling, per-thread data, and threads and libraries, see the ChorusOS 5.0 Application Developer's Guide.

Within an actor, whether user or supervisor, one or more threads may execute concurrently. A thread is the unit of execution in a ChorusOS operating system and represents a single flow of sequential execution of a program. A thread is characterized by a context corresponding to the state of the processor (registers, program counter, stack pointer or privilege level, for example). See Figure 2-4.

Figure 2-4 A Multi-Threaded Actor

Graphic

Threads can be created and deleted dynamically. A thread may be created in an actor other than the one to which the creator thread belongs, provided they are both running on the same machine. The actor in which the thread was created is called the home actor or the owning actor. The home actor of a thread is constant during the life of the thread.

The system assigns decreasing priorities to boot actor threads, so that boot actor main threads are started in the order in which they were loaded into the system image. If a boot actor's main thread sleeps or is blocked, the next boot actor threads will be scheduled for running.

Although there are no relationships maintained by the ChorusOS operating system between the creator thread and the created thread, the creator thread is commonly called the parent thread, and the created thread is commonly called the child thread.

A thread is named by a local identifier referred to as a thread identifier. The scope of this type of identifier is the home actor. In order to name a thread of another actor, you must provide the actor capability and the thread identifier. It is possible for a thread to refer to itself by using the predefined constant: K_MYSELF.

All threads belonging to the same home actor share all the resources of that actor. In particular, they may access its memory regions, such as the code and data regions, freely. In order to facilitate this access, the ChorusOS operating system provides synchronization tools, covered in "Synchronization" in this book.

Threads are scheduled by the microkernel as independent entities The scheduling policy used depends on the scheduling module configured within the system. In a first approach, assume that a thread may be either active or waiting. A waiting thread is blocked until the arrival of an event. An active thread may be running or ready to run.

POSIX Services

The ChorusOS operating system offers a POSIX API for process management. POSIX comprises a set of standard APIs for portable multithreaded programming. The ChorusOS operating system provides the following POSIX APIs:

For a specific POSIX-compatible function to be available, the component in which it is contained must be configured into the operating system. In some cases, a function can be contained in more than one component, therefore, at least one of the components must be selected.

The processes also benefit from the dynamic libraries (DYNAMIC_LIB) and compressed (GZ_FILE) features. Processes can be multi-threaded using the POSIX pthread calls described below. However, the ChorusOS operating system has some limitations regarding multi-threaded processes. It is not possible to invoke either fork() or exec() from a multi-threaded process. Such attempts will fail and report an error code. If a multi-threaded application needs to launch a process, it should use the posix_spawn() system call. However, the ChorusOS implementation of the posix_spawn() call is limited and does not permit handling of file or signal management operations.

Process images in the ChorusOS operating system are loaded from their files and are not mapped in memory, even though the underlying selected memory profile supports paging.

You can set tunable values for the following when you build your system:

User and Supervisor Processes

POSIX processes are divided into two types, user and supervisor processes. The main differences between user and supervisor processes are outlined below:

High Availability

The ChorusOS operating system incorporates several features that provide high availability services, including:

Black Box

The black box feature provides an enhanced mechanism for tracing the activity of the system, so that the exact cause of any failure can be determined quickly and easily.

Black box timer is elaborated further in "Black Box (BLACKBOX)".

Dynamic Reconfiguration

The dynamic process management feature of the ChorusOS operating system allows processes to be loaded dynamically, from either disk or the network, without first halting the system. This provides the basis for a dynamic reconfiguration capability that minimizes service downtime, and keeps existing services available while the system is modified or upgraded. Dynamic reconfiguration also relies on the IPC facilities of the ChorusOS operating system to transfer inbound communication to the new processes transparently.

For example, with the ChorusOS operating system running in a Private Branch Exchange (PBX), features such as call forwarding (or follow me) can be added without interrupting the basic telephone service and without reconfiguring the entire telephone network.

Memory Protection

Different applications can run in different memory address spaces, which are protected from one another. If one application fails, it can corrupt only its own data but cannot corrupt the data of other applications, or of the system itself. This mechanism confines errors and prevents their propagation.

Memory Protection is elaborated further in "Protected Memory (MEM_PROTECTED)".

Watchdog Timer Protection

The watchdog timer feature provides a two-tier watchdog mechanism to monitor hardware and the operating system by checking periodically that they are operating correctly. The application may also be monitored if it uses the debug-aware watchdog timer API.

Watchdog timer is elaborated further in "Watchdog Timer (WDT)".

Real-Time Operation

The ChorusOS operating system provides real-time service through the following features and services, amongst others:

Synchronization

Using mutexes and real-time mutexes. See "Synchronization" for details.

Real-time scheduling

Using pre-emptive FIFO scheduling based on thread priorities. See "First-in-First-Out Scheduling (SCHED_FIFO)" for more information.

High-resolution timer

For fine-grained ordering of events and fault-detection mechanisms between nodes. See "High Resolution Timing" for details.

Reduced context switching
overhead and interrupt latency

By operating at the hardware register level, rather than throughout the file structure.

IPC mail boxes (MIPC)

To provide a shared message space for rapid communication between actors. See "Mailboxes (MIPC)" for more information.

In addition, the ChorusOS operating system offers an implementation of the POSIX real-time API. See "POSIX Services" for a full examination of the implementation of the POSIX real-time API.

Development Lifecycle

This section provides an overview of the stages in using the ChorusOS operating system to develop an application or system. It provides a high-level summary of the tasks described in the ChorusOS 5.0 Application Developer's Guide.

Installing ChorusOS

This section provides a brief overview of the installation process. For full information, see the ChorusOS 5.0 Installation Guide.

Installing the Development Environment on the Host

After installation is complete, the Sun Embedded Workshop software provides a development environment containing all the binary components required to build a ChorusOS operating system image. To create a system image for a particular reference target board, follow the instructions in Part II of the ChorusOS 5.0 Installation Collection.

Setting up a Boot Server

A boot server is a system that provides the ChorusOS operating system image for downloading to target systems. A boot server is useful if you want to make the same image available to many targets. To install an instance of the ChorusOS operating system on a boot server, follow the instructions in the ChorusOS 5.0 Installation Guide. The system where you installed the development environment can be used as a boot server.

Building and Booting on a Target System

When you have created an instance of the ChorusOS operating system you require, including embedded applications, and built a system image, you need to boot it on the target system. There are several ways to do this, including:

Developing an Application

Configuring the System Image

When you develop an application, you must make sure that the instance of the ChorusOS operating system that the application will run on contains the optional components your application requires. For example, if your application uses semaphores, you must include the SEM option. See Appendix A, Optional ChorusOS Operating System Components for information about optional components of the ChorusOS operating system.

Writing an Application

The ChorusOS 5.0 Application Developer's Guide explains the following:

Tuning

When your application is written, you can create a performance profile to check for possible performance improvements. Creating a performance profile will help you to optimize the application's use of the ChorusOS operating system. See "Performance Profiling" in the ChorusOS 5.0 Application Developer's Guide and "Configuring and Tuning" in the ChorusOS 5.0 System Administrator's Guide

Developing a System

Information about advanced programming topics is not provided in this book.

Applications

Users can write their own applications in C, C++, or Java.

The ChorusOS operating system is able to load binary files of user applications from the host system acting as an NFS server, from a local disk, or from the system image itself (/image/sys_bank). This host-target environment allows you to load supervisor and user actors using a simple remote shell mechanism.