ChorusOS 4.0 Introduction

Chapter 1 Technical Overview

This chapter contains an overview of Sun Embedded WorkshopTM.

Introduction to Sun Embedded Workshop

Sun Embedded Workshop provides the ChorusOSTM operating system and a complete development environment for creating an application that runs on the ChorusOS operating system or an embedded system based on the ChorusOS operating system.

High-performance and high-availability, combined with a simple, flexible configuration mechanism make Sun Embedded Workshop particularly well-adapted for developing and deploying a wide range of telecommunications, data communications, and consumer applications.

Sun Embedded Workshop Components

Sun Embedded Workshop contains the following components:

Supported Processor Families

This release of Sun Embedded Workshop is available for the following development platforms:

See the ChorusOS Release Notes for the latest information about supported target platforms.

Features and Benefits

This section contains a summary of the key features and benefits of Sun Embedded Workshop.

Multi-platform Development Environment

Sun Embedded Workshop provides complete support, tools, and libraries for developing C and C++ applications on a range of supported platforms. Development takes place on one system (the host), even though the software will eventually run on a very different device (the target), or on a variety of targets.

Sun Embedded Workshop 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.

Portable Binary System

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

Super-Configurability

Sun Embedded Workshop 4.0 uses a flexible, component-based architecture that allows different services to be configured into the runtime instance of the ChorusOS operating system.

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 very accurately configured to meet the exact needs of a given application or environment, saving on memory and improving performance.

The core executive can support multiple, independent applications running in both user and supervisor memory space.

This flexible architecture is shown in Figure 1-1. Detailed descriptions of the optional features for the ChorusOS operating system are provided in "Operating System Components".

Figure 1-1 Component-based Operating System Architecture

Graphic

By taking advantage of the component-based architecture, the application designer 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:

High Availability

Building large, highly-available systems is a complex and challenging undertaking that has required significant advances in design, implementation, and testing methodologies. For example, the telecommunications industry faces severe reliability and availability constraints imposed by international standards and market pressure. Yet, until recently, very few commercially available operating systems could provide the appropriate level of support to be able to offer true 7 by 24 operation.

The ChorusOS operating system incorporates several features that successfully address the needs of this demanding market, including:

Memory Protection

Different applications can run in different memory address spaces 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.

Hot Restart

An important benefit of the ChorusOS operating system is its hot restart capability, which provides one of the fastest mechanisms available in the industry today for restarting applications or entire systems if a serious error or failure occurs.

The conventional technique, cold restart, involves rebooting or reloading an application from scratch. This causes unacceptable downtime in most systems, and there is no way to return the application to the state in which it was executing when the error occurred.

The ChorusOS hot restart feature allows execution to recommence without reloading code or data from the network or from disk. When a hot-restartable process fails, persistent memory is preserved, its text and data segments are reinitialized to their original content without accessing stable storage, and the process resumes at its entry point. Hot restart is significantly faster than the conventional cold restart technique and retains the critical information that allows an application to be reconstructed quickly with little or no interruption of service. Furthermore, the hot restart technique has been applied to the entire ChorusOS operating system and not only to the applications it runs, thus ensuring a very high quality of service availability.

For detailed information about the hot restart feature, refer to the ChorusOS 4.0 Hot Restart Programmer's Guide.

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 inter-process communication (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), new features such as call forwarding (or follow me) can be added without interrupting the basic telephone service and without reconfiguring the entire telephone network.

Support for Legacy APIs

One of the challenges facing software developers working in the telecommunications and data communications industries is the need to select the most appropriate of the proliferation of public standards and proprietary solutions available to them. By investing in a given solution, application vendors and service providers can quickly find themselves locked into a legacy API that once seemed to offer state-of-the-art functionality. In some cases, finding that they can no longer keep pace with emerging technology, they are forced to either fall behind or to abandon their original investment.

The ChorusOS operating system offers software developers a way to protect their existing investments, while providing a smooth migration path to new platforms running the ChorusOS operating system. It does this by:

Support for Java(TM) Applications

The ChorusOS operating system provides an execution environment that, when combined with a Java(TM) Runtime Environment (JRE), supports real-time applications and Java applications running on the same machine, each in the appropriate environment.

Transparent Inter-Process Communication (IPC)

Based on industry standards, the Transparent Inter-Process Communication (IPC) facility of the ChorusOS operating system allows applications to be distributed across multiple machines, and to run in a heterogeneous environment that comprises hardware and software with stark operational and programming incompatibilities.

At a lower level, one of the components of the ChorusOS operating system provides transparent IPC that recognizes whether a given process is available locally, or is installed on a remote system that is also running the ChorusOS operating system. When a process is accessed, the IPC identifies the shortest path and quickest execution time that can be used to reach it, and communicates in a manner that makes the location entirely transparent to the application.

Operating System Components

Optional features are implemented as components that can be added to, or removed from, an instance of 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 is always present in an instance of the ChorusOS operating system. Optional components in the operating system provide the following services:

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 instance of the operating system, the function is available to be called. Some library functions are independent of any specific component and are always available.

The following sections provide detailed descriptions of the various optional components of the operating system. Each component is identified by a name which is used by the configuration tools and within applications.

Table 1-1 shows the component groups.

Table 1-1 Operating System Optional Components
 Component Name
 Actor management
   Dynamic actor loading managementACTOR_EXTENDED _MNGT
   User-mode extension supportUSER_MODE
   Dynamic librariesDYNAMIC_LIB
   Compressed file managementGZ_FILE
 Scheduling
  POSIX round-robin scheduling classROUND_ROBIN
 Memory management
  Virtual (user and supervisor) address spaceVIRTUAL_ADDRESS_ SPACE
   On-demand pagingON_DEMAND_PAGING
 Hot restart and persistent memory
  Hot restartHOT_RESTART
 Inter-thread communication
   SemaphoresSEM
   Event flag setsEVENT
   Mutual exclusion locks supporting thread priority inversion avoidanceRTMUTEX
 Time management
   Periodic timersTIMER
   Thread and actor virtual timerVTIMER
   Date and time of dayDATE
   Real-time clockRTC
 Inter-process communication
   Location-transparent inter-process communicationIPC
  Remote (inter-site) IPC supportIPC_REMOTE
  Remote IPC communications mediumIPC_REMOTE_COMM
   Mailbox-based communications mechanismMIPC
   POSIX 1-compliant message queuesPOSIX_MQ
   POSIX 1-compliant shared memory objectsPOSIX_SHM
 LAP
  Local name server for LAP bindingLAPBIND
  LAP validity-check optionLAPSAFE
 Tools support
   Message loggingLOG
  Profiling and benchmark supportPERF
  System monitoringMON
  System debuggingDEBUG_SYSTEM
 C_INIT
  Basic command interpreter on targetLOCAL_CONSOLE
  Remote shellRSH
 File system options
   Named pipesFIFOFS
  NFS clientNFS_CLIENT
  NFS serverNFS_SERVER
  MS-DOS file systemMSDOSFS
  UFS file systemUFS
 I/O management
   Network packet filterBPF
  Swap supportFS_MAPPER
  Driver for IDE diskIDE_DISK
  /dev/mem, /dev/kmem, /dev/null, /dev/zero DEV_MEM
  Support for RAM diskRAM_DISK
  Support for FLASH mediaFLASH
  Virtual TTYVTTY
  Driver for SCSI diskSCSI_DISK
 Support for IPCIOM_IPC
 Support for OSIIOM_OSI
 Networking
  Serial link IPSLIP
   POSIX 1003.1g-compliant socketsPOSIX_SOCKETS
   Point-to-point protocolsPPP
   Local sockets and pipesAF_LOCAL
 Administration
   ChorusOS statisticsADMIN_CHORUSSTAT
  ifconfig administration commandADMIN_IFCONFIG
  mount administration commandADMIN_MOUNT
  rarp administration commandADMIN_RARP
  route administration commandADMIN_ROUTE
  shutdown administration commandADMIN_SHUTDOWN
  netstat administration commandADMIN_NETSTAT

Not all these components are supported on all platforms. See the appropriate book in the ChorusOS 4.0 Target Family Documentation Collection for details of which components are available for your platform.

Some options are dependent on others. These dependencies are managed automatically by the configuration tools and it is not necessary to include prerequisite options explicitly. Some options are mutually exclusive, and the configuration tools will not permit you to include more than one option from a mutually exclusive set.

The Core Executive

The essential services required to support real-time applications are provided by the executive. The core executive can support multiple, multi-threaded applications running in both user and supervisor memory space. It provides the following kernel functionality:

See CORE(5FEA) for further details.

Optional Operating System Services

Actor Management

ACTOR_EXTENDED_MNGT

The ACTOR_EXTENDED_MNGT feature provides extended management functions for actors, including dynamic loading and control of actors. This feature also provides the underlying support for more advanced features such as support of dynamically loadable libraries (DYNAMIC_LIB) and uncompression of actors or libraries at load time (GZ_FILE).

For more details, see ACTOR_EXTENDED_MNGT(5FEA).

USER_MODE

This feature provides support for unprivileged actors, running in separate virtual user address spaces (when available).

USER_MODE is used in all memory models. For more details, see USER_MODE(5FEA).

DYNAMIC_LIB

The DYNAMIC_LIB feature provides support for dynamic libraries within Sun Embedded Workshop. It requires the ACTOR_EXTENDED_MNGT feature, so that actors can be linked with dynamic libraries. These libraries are loaded and mapped within the actor address space at execution time. Symbol resolution is performed at library load time. This feature also enables a running actor to ask for a library to be loaded and installed within its address space, and then to resolve symbols within this library. The feature handles dependencies between libraries.

For more details, see DYNAMIC_LIB(5FEA).

GZ_FILE

The GZ_FILE feature enables dynamically loaded actors and dynamic libraries to be uncompressed at load time, prior to execution. This minimizes the space required to store these compressed files, and the download time. The GZ_FILE feature requires the ACTOR_EXTENDED_MNGT feature.

For more details, see GZ_FILE(5FEA).

Scheduling

A scheduler is a feature which provides scheduling policies. A scheduling policy is a set of rules, procedures, or criteria used in making processor scheduling decisions. Each scheduler feature implements one or more scheduling policies, interacting with the core executive according to a defined kernel internal interface. A scheduler is mandatory in all kernel instances. The core executive includes the default FIFO scheduler.

The default scheduler present in the core executive implements a CLASS_FIFO scheduling class, which provides simple pre-emptive scheduling based on thread priorities.

More detailed information about these scheduling classes is found in threadScheduler(2K).

For more details on scheduling, see SCHED(5FEA).

ROUND_ROBIN

The optional ROUND_ROBIN scheduler feature enables the additional CLASS_RR scheduling class, which is similar to CLASS_FIFO but adds round-robin time slicing based on a configurable time quantum.

For more details, see ROUND_ROBIN(5FEA).

Memory Management

There are three memory management models, MEM_FLAT, MEM_PROTECTED, and MEM_VIRTUAL. The model used is determined by the settings of the VIRTUAL_ADDRESS_SPACE and ON_DEMAND_PAGING features. See MEM(5FEA) for more details.

VIRTUAL_ADDRESS_SPACE

The VIRTUAL_ADDRESS_SPACE feature enables separate virtual address space support using the MEM_PROTECTED memory management model. If this feature is disabled all the actors and the operating system share one single, flat, address space. When this feature is enabled a separate virtual address space is created for each user actor.

ON_DEMAND_PAGING

The ON_DEMAND_PAGING feature enables on demand memory allocation and paging using the MEM_VIRTUAL model. ON_DEMAND_PAGING is only available when the VIRTUAL_ADDRESS_SPACE feature is enabled.

Normally when a demand is made for memory, the same amount of physical and virtual memory is allocated by the operating system. When the ON_DEMAND_PAGING feature is enabled, virtual memory allocation of the user address space does not necessary mean that physical memory will be allocated. Instead, the operating system may allocate the corresponding amount of memory on a large swap disk partition. When this occurs, physical memory will be used as a cache for the swap partition.

Hot Restart and Persistent Memory Management

The HOT_RESTART feature provides support for rapidly reloading and reinitializing failed ChorusOS operating system actors, without accessing stable storage. Actors which benefit from this support are known as restartable actors. HOT_RESTART also provides all actors (not just restartable actors) with a means of storing persistent data, data which can persist beyond the lifetime of a run-time instance of an actor.

The main services exported by the HOT_RESTART feature are:

For more details, see HOT_RESTART(5FEA)

Inter-thread communication

The ChorusOS operating system provides the following services to support multithreaded programming:

SEM

The SEM feature provides semaphore synchronization objects. A semaphore is an integer counter and an associated thread wait queue. When initialized, the semaphore counter receives a user-defined positive or null value.

Two main atomic operations are available on semaphores: P (or pass) and V (or free).

Semaphores are data structures allocated in the actors' address spaces. No kernel data structure is allocated for these objects. They are simply designated by the address of the structures. The number of these types of objects that threads may use is therefore unlimited.

For more details, see SEM(5FEA).

EVENT

The EVENT feature provides the management of event flag sets.

An event flag set is a set of bits in memory that is associated with a thread wait queue. Each bit is associated with one event. Event flag sets are data structures allocated in the actors' address spaces. No kernel data structure is allocated for these objects. They are simply designated by the address of the structures. The number of these types of objects that threads may use is therefore unlimited.

When a flag is set, it is said to be posted, and the associated event is considered to have occurred. Otherwise the associated event has not yet occurred. Both threads and interrupt handlers can use event flag sets for signaling purposes.

A thread can wait on a conjunctive (and) or disjunctive (or) subset of the events in one event flags set. Several threads may be pending on the same event. In that case, each of the threads will be made eligible to run when the event occurs.

For more details, see EVENT(5FEA).

RTMUTEX

The RTMUTEX feature provides mutual exclusion locks, using a priority inheritance protocol, in order to avoid thread priority inversion problems.

For more details, see RTMUTEX(5FEA).

Time Management

The ChorusOS operating system provides the following time management features:

The interrupt-level timing feature is always available and provides a traditional, one-shot time-out service. Time-outs and the time-out granularity are based on a system-wide clock tick.

When the timer expires, a caller provided handler is executed directly at the interrupt level. This is generally on the interrupt stack, if one exists, and with thread scheduling disabled; therefore, the execution environment is restricted accordingly.

TIMER

The TIMER feature implements a high-level interval timing service for both user and supervisor actors. It includes one-shot and periodic timers. The time-out notification is achieved through user-provided handler threads which are woken up in the application actor. Handler threads may invoke any kernel or subsystem system call.

For more details, see TIMER(5FEA).

VTIMER

The virtual time option provides a number of functions that are typically used by higher-level operating systems for controlling and accounting thread-execution.

Virtual time-outs can be set on:

A virtual time-out handler is entered as soon as one or more designated threads have consumed the specified amount of execution time.

Execution accounting may be limited to execution within the home actor of the thread (internal execution time) or may be extended to include cross-actor invocations, such as system calls (total execution time).

For more details, see VTIMER(5FEA).

DATE

The DATE feature maintains the time of day expressed in Universal Time, which is defined as the interval since 1st January 1970. Since the concept of local time is not supported directly by the operating system, time-zones and local seasonal adjustments must be handled by libraries outside the kernel.

For more details, see DATE(5FEA).

RTC

The RTC feature indicates whether a real-time clock (RTC) device is present on the target machine. When this feature is set, and an RTC is present on the target, the DATE feature will retrieve time information from the RTC. If the RTC feature is not set, indicating an RTC is not present on the target, the DATE feature will emulate the RTC in software.

For more information, see RTC(5FEA).

Inter-process communication

The ChorusOS operating system provides Inter Process Communication (IPC), allowing threads to communicate and synchronize, even when they do not share the same memory space.

Communication is achieved by the exchange of messages through ports, and IPC supports port migration, whereby the messages sent to a given port can be transferred to a new process in a way that is transparent to the application.

The ChorusOS operating system also includes a mailbox (MIPC) mechanism that provides a shared communication environment for actors within an application.

IPC

The IPC feature provides powerful asynchronous and synchronous communication services.

The IPC feature exports the following basic communication abstractions:

The IPC feature allows threads to communicate and synchronize when they do not share memory, for example when they do not run on the same node.

For more details, see IPC(5FEA).

For information on how to configure IPC for local, Ethernet, and VME use, see Appendix A, Configuring IPC.

IPC_REMOTE

When the IPC_REMOTE feature is set, IPC services are provided in a distributed, location-transparent way, allowing applications distributed across the different nodes, or sites, of a network to communicate as if they were co-located on the same node.

For information on how to configure IPC for local, Ethernet, and VME use, see Appendix A, Configuring IPC.

IPC_REMOTE_COMM

If you set IPC_REMOTE, you can specify the communication method by setting the IPC_REMOTE_COMM feature. By default, this is set to EXT for external networking protocols. You can also set it to VME, and have the communication managed by the kernel directly.

For information on how to configure IPC for local, Ethernet, and VME use, see Appendix A, Configuring IPC.

MIPC

The optional MIPC feature is designed to allow an application composed of one or multiple actors to create a shared communication environment (or message space) within which these actors can exchange messages in a very efficient way. In particular, supervisor and user actors of a same application can exchange messages with the MIPC service. Furthermore, these messages can be initially allocated and sent by interrupt handlers in order to be processed later in the context of threads.

See Chapter 8, Inter-actor Communication for more information about using message spaces.

For more details of the MIPC feature, see MIPC(5FEA).

POSIX_MQ

The POSIX_MQ feature is a compatible implementation of the POSIX 1 real-time message queue API. For general information on this feature, see intro(2POSIX), and the POSIX standard (IEEE Std 1003.1b-1993).

For more details, see POSIX_MQ(5FEA).

POSIX_SHM

The POSIX_SHM feature is a compatible implementation of the POSIX 1 real-time shared memory objects API. For general information on this feature, see intro(2POSIX), and the POSIX standard (IEEE Std 1003.1b-1993).

For more details, seePOSIX_SHM(5FEA).

LAP

Low overhead, same-site invocation of functions and APIs exported by supervisor actors may be done through use of Local Access Points (LAPs). A LAP is designated and invoked via its LAP descriptor. This may be directly transmitted by a server to one or more specific client actors, via shared memory, or as an argument in another invocation. In addition, optional extensions provide safe on-the-fly shutdown of local service routines and a local name binding service (see the LAPSAFE and LAPBIND features).

See CORE(5FEA) for further details.

LAPBIND

The LAPBIND feature provides a nameserver from which a LAP descriptor may be requested and obtained indirectly, using a static symbolic name which may be an arbitrary character string. Using the nameserver, a LAP may be exported to any potential client that knows the symbolic name of the LAP (or of the service exported via the LAP).

For more details, see LAPBIND(5FEA).

LAPSAFE

The LAPSAFE feature does not export an API directly. It modifies the function and semantics of local access point creation and invocation. In particular, it enables the K_LAP_SAFE option (see svLapCreate(2K)), which causes validity checking to be turned on for an individual LAP. If a LAP is invalid or has been deleted, lapInvoke() will fail cleanly with an error return. Furthermore, the svLapDelete() call will block until all pending invocations have returned. This option allows a LAP to be safely withdrawn even when client actors continue to exist. It is useful for clean shutdown and reconfiguration of servers.

The LAPSAFE feature is a prerequisite for HOT_RESTART.

For more details, see LAPSAFE(5FEA).

Tools support

The ChorusOS operating system provides the following support for debugging.

LOG

The LOG feature provides support for logging console activity on a target system.

For more details, see sysLog(2K).

PERF

The PERF feature provides an API to share the system timer (clock) in two modes:

The PERF API closely follows the timer(9DDI) device driver interface.

For more details see PERF(5FEA).

MON

The MON feature provides a means to monitor the activity of kernel objects such as threads, actors, and ports. Handlers can be connected to the events related to these objects so that, for example, information related to thread-sleep/wake events can be known. Handlers can also monitor global events, affecting the entire system.

For more details see MON(5FEA).

DEBUG_SYSTEM

The DEBUG_SYSTEM feature enables remote debugging of the ChorusOS operating system with the XRAY Debugger for ChorusOS. XRAY communicates with the ChorusOS debug server (see chserver(1CC)) through the RDBS protocol adapter (see rdbs(1CC)), both running on the host. The debug server in turn communicates with the debug agent running on the target. The debug server exports an open Debug API, which is documented and available for use by third party tools.

For more details see DEBUG_SYSTEM(5FEA).

C_INIT Options

LOCAL_CONSOLE

This feature gives access to C_INIT commands through the local console of the target. When this feature is set, the C_INIT console command starts the command interpreter on the local console. console is usually run at the end of the sysadm.ini file. It can also be run through rsh if it is available.

See C_INIT(1M) for a detailed description of console and other C_INIT commands.

RSH

This feature gives access to C_INIT commands through the rsh service. When this feature is set, the C_INIT command rshd starts the rsh demon. rshd is usually run from the end of the sysadm.ini file. It can also be run from the local console if it is available.

See C_INIT(1M) for a detailed description of rshd and other C_INIT commands.

File System Options

The ChorusOS operating system supports the following types of file system:

FIFOFS

The FIFOFS feature provides support for named pipes. It requires either NFS_CLIENT or UFS to be configured as well as POSIX_SOCKETS and AF_LOCAL.

For more details, seeFIFOFS(5FEA).

NFS_CLIENT

The NFS_CLIENT feature provides POSIX-compatible file I/O system calls on top of the NFS file system. It provides only the client side implementation of the protocol and thus requires a host system to provide the server side implementation of the NFS protocol. The NFS_CLIENT feature can be configured to run on top of either Ethernet, PPP or SLIP. The NFS_CLIENT requires the POSIX_SOCKETS feature to be configured.

For more details, see NFS_CLIENT(5FEA).

NFS_SERVER

The NFS_SERVER feature provides the services to provide an NFS server on top of a local UFS file system. It provides only the server side implementation of the protocol, the client side being provided by the NFS_CLIENT feature. The NFS_SERVER requires POSIX_SOCKETS and UFS.

For more details, see NFS_SERVER(5FEA).

MSDOSFS

The MSDOSFS feature provides POSIX-compatible file I/O system calls on top of the MSDOSFS file system on a local disk. It requires a local disk to be configured and accessible on the target system.

At least one of RAM_DISK, IDE_DISK or SCSI_DISK must be configured. It is usually embedded in any configuration which uses a file system as part of the boot image of the system. MSDOSFS is frequently used with Flash memory.

For more details, see MSDOSFS(5FEA).

UFS

The UNIX file system option provides support for a disk-based file system, that is, the file system resides on physical media such as hard disks.

The UNIX file system option supports drivers for the following types of physical media:

For more details, see UFS(5FEA).

I/O Management

The ChorusOS operating system provides the following I/O management services:

BPF

The BPF feature provides a raw interface to data link layers in a protocol independent fashion. All packets on the network, even those destined for other hosts, are accessible through this mechanism. It must be configured when using the ADMIN_RARP feature, or Dynamic Host Configuration Protocol client (dhclient(1M)).

For more details, see BPF(5FEA).

FS_MAPPER

The FS_MAPPER feature provides support for swap in the IOM. It requires either the IDE_DISK or SCSI_DISK to be configured, as well as VIRTUAL_ADDRESS_SPACE and ON_DEMAND_PAGING.

For more details, see FS_MAPPER(5FEA).

IDE_DISK

The IDE_DISK feature provides an interface to access IDE disks. These disks may then be initialized and used as regular file systems. The IDE_DISK feature relies on the IDE bus support provided by the BSP to get access to disks connected on that bus.

For more details, see IDE_DISK(5FEA).

DEV_MEM

The DEV_MEM feature provides a raw interface to memory devices such as /dev/zero, /dev/null, /dev/kmem and /dev/mem.

For more details, see DEV_MEM(5FEA) .

RAM_DISK

The RAM_DISK feature provides an interface to chunks of memory which can be seen and handled as disks. These disks may then be initialized and used as regular file systems, although their contents will be lost at system shutdown time. This feature is also required to get access to the MS-DOS file system which is usually embedded as part of the system boot image.

For more details, see RAM_DISK(5FEA).

FLASH

The FLASH feature provides an interface to access a memory device. The flash memory may then be formatted, labelled and used to support regular file systems. The FLASH feature relies on the flash support based on the Flite 1.2 BSP, and is not supported for all target family architectures. See the appropriate book in the ChorusOS 4.0 Target Family Documentation Collection for details of which target family architecture supports the Flite 1.2 BSP.

For more details, see FLASH(5FEA).

VTTY

The VTTY feature provides support for serial lines on top of the BSP driver for higher levels of protocols. It is used by the SLIP and PPP features.

For more details, see VTTY(5FEA).

SCSI_DISK

The SCSI_DISK feature provides an interface to access SCSI disks. The SCSI_DISK feature relies on the SCSI bus support provided by the BSP to access disks connected on that bus.

For more details, see SCSI_DISK(5FEA).

IOM_IPC

The IOM_IPC feature provides support for the ethIpcStackAttach(2K) system call and the corresponding built-in C_INIT(1M) command, ethIpcStackAttach. If the feature is not configured, the ethIpcStackAttach(2K) system call of the built-in C_INIT command will display an error message.

If the IOM_IPC feature is set to true, an IPC stack is included in the IOM system actor. The IPC stack may be attached to an Ethernet interface.

For more details, see IOM_IPC(5FEA).

IOM_OSI

The IOM_OSI feature provides support for the ethOSIStackAttach(2K) system call.

If the IOM_OSI feature is set to true, an OSI stack is included in the IOM system actor. The OSI stack may be attached to an Ethernet interface.

For more details, see IOM_OSI(5FEA).

Networking

The following features provide various methods of networking on the target:

SLIP

The SLIP feature allows serial lines to be used as network interfaces. This feature needs to be configured in order to fully support the ADMIN_SLIP feature as well as the various slip related commands provides by the Sun Embedded Workshop system.

For more details, see SLIP(5FEA).

POSIX_SOCKETS

The POSIX_SOCKETS feature provides a TCP/IP stack through POSIX-compatible socket system calls. For general information on this feature, see intro(2POSIX) and the POSIX draft standard P1003.1g. However, POSIX_SOCKETS only provides support of the AF_INET domain. The AF_LOCAL domain support is provided by the AF_LOCAL feature.

For more details, see POSIX_SOCKETS(5FEA).

PPP

The PPP feature allows serial lines to be used as network interfaces using the Point-to-Point Protocol. This feature needs to be configured in order to fully support the ADMIN_PPP feature as well as the various PPP related commands provided by the Sun Embedded Workshop system.

For more details, seePPP(5FEA).

AF_LOCAL

The AF_LOCAL feature provides support for the AF_LOCAL domain for sockets. It requires and complements the POSIX_SOCKETS feature which provides the AF_INET domain independently.

For more details, see AF_LOCAL(5FEA).

Administration

The ChorusOS operating system provides the following optional administration features:

ADMIN_CHORUSSTAT

The ADMIN_CHORUSSTAT feature provides support for the built-in chorusStat command of C_INIT(1M). If the feature is not configured, the built-in C_INIT command will display an error message. This feature affects the content of the ADMIN system actor. For more information on the chorusStat service, refer to chorusStat(1CC). Note that even if the ADMIN_CHORUSSTAT feature is not configured, you can get the ChorusOS operating system statistical information by running the chorusStat command, which is a stand-alone version of the built-in C_INIT command.

For more details, see ADMIN_CHORUSSTAT(5FEA).

ADMIN_IFCONFIG

The ADMIN_IFCONFIG feature provides support for the built-in ifconfig command of C_INIT(1M). If the feature is not configured, the built-in C_INIT command will display an error message. This feature affects the content of the ADMIN system actor. For more information on the ifconfig service, refer to ifconfig(1M). Note that even if the ADMIN_IFCONFIG feature is not configured, you can configure network interface parameters by running the ifconfig command which is a stand-alone version of the built-in C_INIT command. However, in order to be able to set up the network interface of the target system appropriately at initialization time, the ADMIN_IFCONFIG feature is usually set.

For more details, see ADMIN_IFCONFIG(5FEA).

ADMIN_MOUNT

The ADMIN_MOUNT feature provides support for the built-in mount and umount commands of C_INIT(1M). If the feature is not configured, the built-in C_INIT command will display an error message. This feature affects the content of the ADMIN system actor. For more information on the mount service, refer to mount(1M). This feature provides support to mount and unmount UFS, MS-DOS and NFS file systems. If this feature is not set, there will be no way to run a command to mount a file system within the target system. In this type of configuration, file systems will have to be mounted by user provided applications embedded within the boot image using the mount(2POSIX) system call.

For more details, see ADMIN_MOUNT(5FEA).

ADMIN_RARP

The ADMIN_RARP feature provides support for the built-in rarp command of C_INIT(1M). If the feature is not configured, the built-in C_INIT command will display an error message. This feature affects the content of the ADMIN system actor. For more accurate information on the rarp service, refer to C_INIT(1M). The ADMIN_RARP feature enables the system to retrieve its local IP address using the RARP protocol, and to configure a network interface accordingly. This feature requires the ADMIN_IFCONFIG feature.

For more details, see ADMIN_RARP(5FEA).

ADMIN_ROUTE

The ADMIN_ROUTE feature provides support for the built-in route command of C_INIT(1M). If the feature is not configured, the built-in C_INIT command will display an error message. This feature affects the content of the ADMIN system actor. For more information on the route service, refer to route(1M). Note that even if the ADMIN_ROUTE feature is not configured, you can still manage the routing tables of the Sun Embedded Workshop system by running the route command, which is a stand-alone version of the built-in C_INIT command. However, in order to be able to set up the routing tables of the target system appropriately at initialization time, the ADMIN_ROUTE feature is usually set.

For more details, see ADMIN_ROUTE(5FEA).

ADMIN_SHUTDOWN

The ADMIN_SHUTDOWN feature provides support for the built-in shutdown and reboot commands of C_INIT(1M). If the feature is not configured, the built-in C_INIT commands will display an error message. This feature affects the content of the ADMIN system actor. For more information on the shutdown service, refer to shutdown(1M) . This feature permits the stopping of all or part of the system, and possibly to reboot the system. Note that even if the ADMIN_SHUTDOWN feature is not configured, it may still be possible to stop the system by running the shutdown command, which is a stand-alone version of the built-in C_INIT command.

For more details, see ADMIN_SHUTDOWN(5FEA).

ADMIN_NETSTAT

The ADMIN_NETSTAT feature provides support for the built-in netstat command of C_INIT(1M). If the feature is not configured, the built-in C_INIT command will display an error message. This feature affects the content of the ADMIN system actor. For more information on the netstat service, refer to netstat(1CC). Note that even if the ADMIN_NETSTAT feature is not configured it may still be possible to get the network status by running the netstat command, which is a stand-alone version of the built-in C_INIT command.

For more details, see ADMIN_NETSTAT(5FEA).

Configuring ChorusOS

The ChorusOS operating system provides two standard configuration profiles. These are useful starting points for defining your own configuration.

The 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 IPC over Ethernet and an 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.

The 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.

Development Environment Components

The development environment provided in Sun Embedded Workshop has the following major components:

Debugging Architecture

This release of the ChorusOS operating system introduces an open, debugging architecture, as specified by the ChorusOS Debug Architecture and API Specifications document. The debug architecture relies on a host-resident server which abstracts the target platform to host tools, in particular debuggers. This API specification document is intended to be used by third parties who wish to implement their own debuggers for ChorusOS systems.

The debug server is intended to connect to various forms of target systems, through various forms of connections such as target through serial line, target through Ethernet, core file, target through BDM, or ICE.

This debug architecture provides support for two debugging modes:

In the application debugging mode, debuggers connect to multi-threaded processes or actors. Debugging an actor is non intrusive for the system and other actors, except for actors expecting services from the actor.

In system debugging mode, debuggers connect to the operating system seen as a virtual single multi-threaded process. Debugging the system is highly intrusive, since a breakpoint will stop all system operations. System debugging is designed to allow debugging of all the various parts of the operating system, for example: the boot sequence, the kernel, the BSP and the system protocol stacks.

For more details, see Chapter 10, System and Application Debugging.

Management Utilities

Sun Embedded Workshop 4.0 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.

Development Lifecycle

This section provides an overview of the stages in using Sun Embedded Workshop to develop an application or system. It provides a high-level summary of the tasks described later in this book and elsewhere in the documentation set.

Installing Sun Embedded Workshop

Installing the Development Environment

The ChorusOS 4.0 Installation Guide explains how to download and install Sun Embedded Workshop.

When the installation is complete, you have all the binary components required to build an instance of the ChorusOS operating system. To create a system image, follow the instructions in the appropriate ChorusOS 4.0 Target Family Documentation Collection.

Installing a Boot Server

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

Installing on a Target System

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

Developing an Application

Configuring the System

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 "Optional Operating System Services" for information about optional components of the ChorusOS operating system. See Chapter 3, Configuring and Tuning for information about configuring the ChorusOS operating system to include the components you require.

Writing an Application

Chapter 4, Programming Overview gives a summary of how to use Sun Embedded Workshop to create an application, including the following information:

Chapter 10, System and Application Debugging explains how to debug your application.

Tuning

When your application is written, you can create a performance profile for it, 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 Chapter 11, Performance Profiling for more information.

Developing a System

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