Part I After Installing ChorusOS 5.0

This part introduces the ChorusOS 5.0 System Image and the ChorusOS environments. It explains how to mount the host file system and provides information on configuring and tuning the system.

Chapter 1 Using ChorusOS 5.0

This chapter builds on the material supplied in the ChorusOS 5.0 Installation Guide and describes the ChorusOS operating system in terms of the system image and the basic and extended profiles.

The ChorusOS System Image

The ChorusOS operating system is supplied with two standard images:

• kernonly, which contains the microkernel only and provides a minimal base for porting.

• chorus, which contains a full system image allowing configuration of the whole feature set.

For information about system image components, see "System Image Components"

Refer to the ChorusOS 5.0 Installation Guide for information about downloading and building the kernonly and chorus system images from the distribution. For a definition of the system image, see "the ChorusOS System Image" in ChorusOS 5.0 Application Developer's Guide.

Downloading the System Image

Follow the boot instructions specific to your target, as described in the ChorusOS 5.0 Installation Guide. Further booting information can be found in "The ChorusOS Boot Program" in ChorusOS 5.0 Board Support Package Developer's Guide.

Introducing the Administration Features of the ChorusOS System

Key Commands

An actor is the unit of encapsulation of resources with regard to the ChorusOS microkernel. The special actor called C_INIT is dedicated to administrative commands. The commands contained within C_INIT can be accessed either locally in console mode or remotely from the host, using a remote shell as rsh. See "C_INIT Actor". For more information on rsh, see "Communicating with the Target Using rsh" .

Application actors can either be loaded at boot time, as described in the "ChorusOS Actors" in ChorusOS 5.0 Application Developer's Guide, or dynamically using the C_INIT loading facility. Dynamic loading of actors is also described in further detail in "Execution Environment of Actors and Processes" in ChorusOS 5.0 Application Developer's Guide.

The conf/sysadm.ini file, which is embedded in the system image, is used to specify system initialization commands. The file is read from the /image/sys_bank directory. Each entry of this file is a command to be executed by C_INIT during the microkernel boot. Typical operations in sysadm.ini are network configuration, device initialization and file system mount.

The sysadm.ini file is not accessed remotely at boot time but is included in the system image. Further information on how sysadm.ini is used at start-up is described in "System Start-up".

See also sysadm.ini(4CC) for more information.

C_INIT Actor

The C_INIT actor provides administrative commands for the following:

• file system management, such as partitioning a disk and mounting a file system. This is described in Chapter 3, Introduction to ChorusOS File System Administration.

• network configuration, such as defining IP addresses and initializing network interfaces. This is described in Part III.

• device management, such as binding a high level service (file system, networking, tty management) to an actual device driver. This is described in "Special Device Driver Files".

Here are the most frequently used C_INIT commands:

• mknod: defines special device files.

• mkdev: binds high level services to an instance of a device driver.

• mount, umount: mounts and unmounts file systems.

• arun: launches executables.

• ifconfig: defines IP addresses.

• route, rarp, netstat, ppp, ping: miscellaneous networking commands.

• memstat, chorusStat: prints system statistics.

• setenv, unsetenv, echo, help, sleep, reboot, shutdown: miscellaneous system commands.

• rshd, console, source: specifies the device from which commands can be accepted:

  • rshd: from a host through rsh.

  • console: from system console.

  • source: from a file.

See C_INIT(1M) for a complete description.

These commands are invoked at system start-up, described in the following section, and later during the life of the system. During the life of the system, the C_INIT actor executes commands from the system console, or from a remote host through rsh.

Communicating with the Target Using rsh

For the ChorusOS operating system, commands that would in conventional UNIX systems be run through a shell are in fact run through rsh. The rsh command executes a command on a remote host, passing its input and receiving its output. When the ChorusOS 5.0 operating system image including the rsh feature is booted on the target machine, the C_INIT actor interprets the commands sent from the host through rsh. (See the rshd man page on your host). To see the list of the options available, type:

% rsh target help

where target is the target name or IP address.

The following information is displayed by the C_INIT actor:

C_INIT ChorusOS 5.0.0- valid commands that deal with:

File Systems:
        mount [[-t nfs|ufs|msdosfs|pdevfs] host:pathname|special_file 
	[mount_point]]
        umount [-v|-F|-f|-a|-t nfs|ufs|msdosfs|pdevfs] [special_file]
        swapon [mount_point]

Actors:
        arun [-g rgid] [-S | -U] [-k] [-T] [-d] [-q]
	 [-D] [-Z] [-xip] path [args]
        akill [-s site] {-g rgid | [-c] pid }
        aps 
        umask [mode]
        ulimit [-HSafn] [limit]

Environment variables:
        setenv var value
        unsetenv var
        env 

Networks:
        route 
        netstat 
        ping host
        ifconfig 
        ifwait ifname [timeout, default infinite]
        rarp ethernet_interface_name
        pppd 
        pppclose device
        pppstop 
        ethIpcStackAttach [dtreepath]
        ftpd 
        tftpd

Devices:
        mknod name [b | c] major minor
        dtree 
        mkdev name unit [dtreepath]

This Target:
        reboot 
        restart 
        memstat 
         
This shell:
        echo string
        source filename
        sleep [time in seconds, default=1s]
        help 
        console 
        rshd 
         chorusStat 
        shutdown -i 0|1|2|3

For details of these commands, see C_INIT(1M).

System Start-up

At system start-up, the C_INIT actor executes these steps:

1. Sets up an initial virtual file system.

2. Executes commands from the configuration file sysadm.ini.

3. Executes commands from /etc/rc.chorus when a root file system is mounted (see C_INIT(1M)).

   ---

   Note -

   If the target has a valid IPv4 address, the file /etc/rc.chorus.<ip_address> is selected, if it exists, instead of /etc/rc.chorus. This must be written in the usual dot notation, for example: 192.82.231.1 for IPv4 addresses. IPv6 addresses will be selected arbitrarily by the system; see IPv6 (7P) for further details.

   ---

The initial virtual file system in step 1 contains only two directories, /dev and /image/sys_bank. The /dev directory, initially empty, is used for the definition of special devices, like /dev/tty01. The /image/sys_bank directory contains all the components in the boot image:

• system actors such as C_INIT and drivers.

• system configuration files (sysadm.ini).

• user-defined configuration files and executables.

All of these components can be accessed like the files in an ordinary file system, using their path, for example: /image/sys_bank/sysadm.ini.

The relationship between the conf/sysadmin.ini in the build directory and the /image/sys_bank in the target pseduo filesystem is that conf/sysadmin.ini is used to specify system initialization commands. This file is embedded in the system image during the build and stored in the /image/sys_bank directory.

To access /dev and /image directories on the virtual file system, dev and image directories must be present on your root file system, and this root file system must be mounted.

In step 2, the C_INIT actor executes commands from the configuration file called sysadm.ini. This file contains all the commands needed for the initial administration of the system, including networking, file system management and device management.

The sysadm.ini file can be customized. On the host, it is located in the conf subdirectory of the ChorusOS build directory. This file is automatically embedded in the boot image, in the /image/sys_bank/sysadm.ini file of the initial file system. This allows you to configure embedded targets that do not have access to a local or remote file system.

Security and Password Management

The C_INIT actor authenticates users issuing commands from the host.

The ChorusOS operating system can be configured in secure mode, where remote host access is checked through the /etc/security administration file, located on the target root file system (see security(4CC)). In addition, users' credentials may be specified in this file, overriding default C_INIT configuration values.

If an /etc/security file exists, it must have read permissions for everybody to allow C_INIT to read it with the default credentials (user identifier 0 and group identifier 0). Secure mode is then activated. In this mode, C_INIT authenticates every command it receives from the host. Authentication can fail for two reasons:

• The user name of the remote user which issued the rsh command is not found in the security file.

• The remote host, from which the rsh command came, is not in the remote host's list of users.

In this case, a permission denied message is sent back to the host and the command is aborted.

If the authentication procedure succeeds, the user's privilege credentials (user identifier or uid, group identifier or gid and additional groups) are read from the security file. Trusted users have access to the full set of C_INIT commands.

The ChorusOS operating system also features the ability to manage users' passwords through its password management feature. Related files are located in /etc/master.passwd and /etc/group. The introduction of these files to the ChorusOS operating system enables more flexible security management, in addition to the standard /etc/security file. You can choose to enable the password management feature by running pwd_mkdb.

The C_INIT daemon can run in non-secure mode, in secure mode or in password mode. If C_INIT is running in password mode the login name of the user is first identified in /etc/spwd.db, and then in /etc/security for additional information, such as remote host access permission. If the latter file does not exist, default values apply. If C_INIT is running in secure mode, the login name of the user is identified only in /etc/security.

If C_INIT is runing in non-secure mode, every user is treated as a trusted user and inherits the C_INIT default credentials , uid 0 and gid 0. These are by default zero.

In this case, if the host machine has exported the file system to be mounted with the default mapping of root to nobody, it is necessary that read and execute permissions for the target executable files be given to everybody. Otherwise C_INIT will not have the right to execute the application binaries.

To override the default credentials uid 0 and gid 0, you can use environment variables; these enable you to modify the system dynamically. To modify the deafult credentials:

$ rsh target setenv CINIT_DEFAULTUID some_value
$ rsh target setenv CINIT_DEFAULTGID some_value

Another way to circumvent the problem of C_INIT not having the right to execute the application binaries is by inhibiting the mapping of root to nobody on the host.

The /etc/ldap.conf file contains information about the location of the LDAP server for password management. Information about this file is contained in ldap.conf(4CC).

Further information on password management and how it affects various secure operations in this version of the ChorusOS operating system can be found in these man pages: getpwnam(3STDC), getgrent(3STDC), ,passwd(1M), pwd_mkdb(1M). group(4CC), rshd(1M), ftpd(1M), telnetd(1M).

System Crash and the SYSTEM_DUMP Utility

This feature requires to you to have the HOT_RESTART and BLACKBOX features set to true. You must also have a TFTP daemon running on the host server.

If a microkernel crash occurs in the ChorusOS operating system, the SYSTEM_DUMP feature enables you to read blackbox information. If the microkernel raises an exception, the SYSTEM_DUMP panic handler saves specific information. This is dumped into a persistent memory area, allocated at boot time. The feature then forces a hot reboot to reset the microkernel to a stable state. After reboot, a special actor called the system dump actor uses TFTP to dump an ASCII file on your predetermined host. This ASCII file contains the information contained in the BLACKBOX facility.

The iom.wdt.sysdump tunable is common to both system dump and watchdog timer. The value of iom.wdt.sysdump is set to 0 by default.

If the value of this tunable is set to 1, SYSTEM_DUMP is true and the watchdog timer feature, (feature name: WDT) is true, a system dump is triggered on the host server when the watchdog timer expires.

For more information, consult SYSTEM_DUMP(5FEA).

Management Utilities

The essential management utilities offered by the ChorusOS operating system include:

• Netboot: Boots the ChorusOS operating system remotely using TFTP, when the target does not provide an embedded boot facility.

• Default Console: Directs all console I/O to a local display or to a remote host via a serial line.

• Remote Shell: Executes commands remotely on the target from the host. In particular, this feature allows applications to be loaded dynamically.

• Resource Status: Lists the current status of all operating system resources, for example, actors, threads and memory.

• Logging (Feature name:LOG): Logs operating system events as they occur on the target.

• Monitoring (Feature name:MON). Monitors operating system objects, so that user defined routines are called when certain operations are performed on specified objects.

• Profiling : Runs profiling sessions on system applications.

• Benchmarking: Benchmarks the operating system.

• Watchdog Timer: Monitors the ChorusOS operating system and, should a crash occur, the timer expires. Diagnostic information is then collected, if possible, as described in the "System Crash and the SYSTEM_DUMP Utility". This implementation of the WDT API supports a maximum of one watchdog timer.

• Black Box: Comprises a set of microkernel ring buffers to provide real time collection and storage of historical event information leading up to a system failure.

Input/Output Management

When actors use the ChorusOS Console Input/Output Application Programming Interface, (API), all I/O operations (such as printf() and scanf()) are directed to the system console of the target. Other APIs available include the Microkernel API, the Private Data API and the Standard-C API. These are described in "ChorusOS APIs" in ChorusOS 5.0 Application Developer's Guide.

If an application uses the ChorusOS POSIX Input/Output API and is spawned from the host with rsh, the standard input and output of the application will be inherited from the rsh program and sent to the terminal emulator on the host on which the rsh command was issued.

Chapter 2 Configuring and Tuning

This chapter explains how to configure and tune a ChorusOS operating system.

• "Configuration Options" explains which items can be configured and how they are defined.

• "Configuration Tools" explains how to configure your system.

The ChorusOS operating system offers a high degree of flexibility, allowing you to tailor the system configuration to the requirements of your application. Depending on the system configuration, applications are offered a range of APIs and a range of development environment tools. Two configuration profiles are included in this ChorusOS operating system delivery: a basic configuration profile and an extended configuration profile. You can use one of these configuration profiles as the starting point for configuring your ChorusOS operating system. See "Configuration Profiles".

An additional chapter focusing on configuring your system image with complete file system support, is also provided. See Chapter 4, Configuring the System Image with File System Support.

The ChorusOS operating system performance can be analyzed and optimized using its performance profiling system. This is described in "Performance Profiling" in ChorusOS 5.0 Application Developer's Guide.

Configuration Options

Configuring a ChorusOS operating system means defining all the components, and their characteristics, that are assembled to form a system image. There are several types of configuration options:

• Feature options: the ChorusOS operating system features.

• Static tunable parameters.

• Dynamic tunable parameters (the environment).

• System image components: system and application actors that are loaded at system boot time.

Configuration settings, including the configuration profile definitions are stored in the configuration directory, conf, in your system image build area. The configuration directory is read and updated by both the command-line and graphical configuration tools.

Feature Options

A ChorusOS feature is a boolean variable, whose value determines whether or not a particular component is included in the system image. Setting a feature to true results in code being added to the microkernel, providing additional services such as file system handlers, or networking protocols.

Feature options within the ChorusOS operating system are listed in "ChorusOS Operating System Features" in ChorusOS 5.0 Features and Architecture Overview.

Configuration Profiles

The ChorusOS operating system provides two pre-defined configuration profiles, the basic profile and the extended profile, to help you select an initial configuration for the operating system. These profiles include or remove certain features in the system.

The extended profile is the default profile, and does not need to be explicitly specified.

The basic configuration profilecorresponds to a realistic configuration, keeping the footprint small. With this configuration, applications are usually embedded in the system image and launched either at boot time or subsequently from the image file system or the boot file system. This configuration uses the flat memory model, to minimize the footprint.

In the basic profile, application actors are loaded at boot time as part of the system image. These actors are also known as boot actors.

When the system boots, actors included in the system image are loaded. For each actor, a thread is created and starts running at the actor's program entry point.

For instructions on building an application actor, embedding it in the system image and running it in the basic profile, consult the ChorusOS 5.0 Application Developer's Guide.

The extended configuration profile corresponds to a reference configuration for telecommunications systems. It includes support for networking using remote IPC over Ethernet and an NFS client. This uses the protected memory model.

Table 2-1 shows the settings of all the features in the extended and basic configuration profiles.

The MONITOR feature is an internal feature used only by the C Virtual Machine, (CVM), a compact Java Virtual Machine.

Both configuration profiles include support for system debugging.

You can use one of these configuration profiles as the initial configuration for your system, and add or remove specific feature options using the configurator utility (see "Command-line Configuration Tool"). Once you have created your initial configuration, you can also use the graphical configuration tool ews (see "The Embedded Workshop Graphical Configuration Tool") to manage the configuration.

Tunable Parameters

Tunable parameters are system parameters which affect system behavior and capabilities. They are used to configure the microkernel and the included features, to change their behavior, and adapt them to your needs. Typical examples of tunables are: maximum number of microkernel objects, scheduler type and attributes for threads, or system clock frequency. Each system component or feature adds a number of these tunable parameters.

Static Parameters

Static parameters are tunable parameters whose values are set permanently within a system image. Changing these values requires rebuilding the system image.

The procedure for assigning new values to tunable parameters is detailed in "Changing Tunable Parameter Values".

Dynamic Parameters

For some tunable parameters, an additional flexibility is offered: the ability to assign values to these parameters at various stages of system production and execution. These types of parameters are called dynamic parameters. These dynamic parameters define the system environment. A basic set of services allows this environment to be constructed and consulted within a system image, at boot time and runtime.

Compared to static parameters, dynamic parameters require additional target data memory in order to store their names and values.

The procedure for modifying dynamic parameters is detailed in "Modifying the System Environment".

System Image Components

The system image contains a configured version of the ChorusOS operating system, and possibly some user-defined applications (actors).

Depending on its configuration options, the ChorusOS operating system is built from a microkernel and a collection of actors. These actors, which contribute to the implementation of some ChorusOS operating system features and system image components are called ChorusOS operating system actors.

Configuration options concerning the system image components or OS actors deal mainly with the inclusion of system and application actors within system images.

Configuration Files

The ChorusOS operating system configuration is expressed in ECML, an XML based language. Further information on ECML is available from "ECML Syntax" in ChorusOS 5.0 Source Delivery Guide. There are several levels of configuration files, all located in the conf directory used to build the system image. They are available to be edited from the conf directory once the system image is built.

Configuration files named in the format xxx.xml can be associated with those in the format xxx_action.xml: the xxx_action.xml usually contains the production rules.

• ChorusOS.xml is the top level configuration file. The entire ChorusOS operating system configuration is accessible through this file, which contains references to all other configuration files.

• typedef.xml contains a definition of generic types. This is not visible from Ews. For more information on Ews, see "The Embedded Workshop Graphical Configuration Tool".

• mkconfig is the directory containing the configuration information for each system component. Most of the information it contains relates to feature options and tunable parameters. For example:

  • mkconfig/kern.xml contains the microkernel feature definitions and dependencies, and contains the tunables for the microkernel. This file also contains default values for the standard configuration.

  • mkconfig/kern_action.xml contains specific configuration actions, including the production rules used internally for the configuration.

  • mkconfig/kern_f.xml and mkconfig/kern_action_f.xml are additional configuration files identified by _f.xml that can be used to manage family-specific configuration options.

  • mkconfig/typedef.xml contains a definition of types for configuration. This is not visible from Ews. For more information on Ews, see "The Embedded Workshop Graphical Configuration Tool".

  • mkconfig/nucleus.xml contains microkernel features and tunables. This file refers to other XML files such as kern.xml, pmm.xml or sysdump.xml.

  • mkconfig/debug.xml contains the debug features and tunables. This file refers to other XML files such as dbgAgent.xml.

  • mkconfig/dbgAgent.xml contains the tunables for System Debug (DEBUG_SYSTEM) feature. Specifies the behavior of the DebugAgent.

  • mkconfig/dbgAgent_action.xml contains associated specific actions related to the DebugAgent.

  • mkconfig/dbgDrv.xml contains tunables to configure the serial line for debugging purposes.

  • mkconfig/dbgDrv_action.xml contains associated actions for debugging purposes.

  • mkconfig/pmm.xml contains persistent memory management tunables.

  • mkconfig/pmm_action.xml contains associated actions.

  • mkconfig/sysdump.xml contains SYSTEM_DUMP tunables.

  • mkconfig/sysdump_action.xml contains SYSTEM_DUMP associated actions.

  • mkconfig/drv.xml defines the DRV_MERGE feature to merge a set of drivers into one (to reduce the image size).

  • mkconfig/os.xml contains the OS features and tunables. This file refers to others files such as cinit.xml or hrCtrl.xml.

  • mkconfig/sys_rule.xml contains Input/Output Management features and tunables.

  • mkconfig/sys_action.xml contains the production rules used internally for Input/Output Manager configuration.

  • mkconfig/cinit.xml contains the command interpreter features such as LOCAL_CONSOLE and rsh.

  • mkconfig/cinit_action.xml contains associated production rules.

  • mkconfig/hrCtrl.xml contains the HOT_RESTART support feature and related tunables, such as maximum number of restart groups and hot restart actors.

  • mkconfig/hrCtrl_action.xml contains associated production rules.

  • mkconfig/monitor.xml contains the monitoring agent feature and related tunables, such as EBD_MONITOR.

• mkimage is the directory containing all the information related to the system image build:

  • mkimage/action.xml contains the production rules for creating the image.

  • mkimage/mkimage.xml contains two configurable declarations:

    • BOOT_MODE is set to ram to build an image for RAM, or rom to build an image for ROM.

    • SYSTEM is set to chorus to build a default system image, or kernonly to build a microkernel-only system image. Other system images are also available.

  • mkimage/family.xml contains the family dependent definitions.

  • mkimage/model.xml contains the binary models for the executable files.

  • mkimage/target.xml contains all configuration options related to the board support package, (BSP), and also the list of drivers. It describes the target specific elements required to build the system image. This is one of the only ChorusOS operating system configuration files that should not be edited. For more information, see the ChorusOS 5.0 Board Support Package Developer's Guide.

  • mkimage/target_action.xml contains actions to produce the system image.

  • mkimage/system.xml contains all system binaries and the configuration of the system image.

  • mkimage/applications.xml describes the applications to be included in the chorus or kernonly system image.

  • mkimage/benchmarks.xml contains a list of the ChorusOS operating system benchmarks to include in the image.

  • mkimage/testsuites.xml contains a list of test suites to include in the image.

  • mkimage/typedef.xml contains generic type definitions for the image (not visible from Ews).

  • mkimage/mkdrv.xml refers to drvlist.xml and mkdrv_action.xml.

  • mkimage/mkdrv_action.xml contains drivers actions.

  • mkimage/drivers.xml contains the list of drivers.

• basic and extended are the two configuration profiles.

Configuration Tools

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

You can use either one of the following configuration tools to view and modify the characteristics of a ChorusOS operating system image:

• The graphical user interface tool for the ChorusOS operating system is called Ews, or Embedded Workshop.

• The command-line interface tool for the ChorusOS operating system is called Configurator.

The Embedded Workshop Graphical Configuration Tool

The graphical configuration tool, Ews, requires Sun Java JDK 1.2 (JAVA 2) to be installed and the location of the Java virtual machine to be in your path.

To start Ews and open an existing configuration file, type:

$ ews -c config-file

The optional config-file specifies the path of the ChorusOS operating system configuration file conf/ChorusOS.xml to open at start-up.

To start Ews without opening a file, type:

$ ews

User Interface Overview

When started, Ews opens a main window, containing a menu bar and toolbar at the top, a navigation tree pane on the left, and an output view pane at the bottom. The rest of the window is occupied by a Multiple Document Interface (MDI) area, which is used to display other windows, like the Properties Inspector, or the Find View (both are described later). These other windows can be resized, moved, or closed just like any other window, but are constrained within the MDI area, and cannot be moved outside.

The main window of Ews is shown in Figure 2-1.

Figure 2-1 Ews User Interface

Navigation Pane

The navigation pane contains two tabbed windows: a Projects tab, which displays any opened configurations as a hierarchical tree, and a Help tab, which displays the online help table of contents.

Within the Project window, every element in the project view tree is represented by a small icon with a name. Right-clicking on an element brings up a floating context menu, which can be used to perform actions such as changing the element's value. Double-clicking on an element opens the main Properties Inspector window in the MDI area.

Within the Help window, selecting an entry in the table of contents displays the appropriate help page in the MDI area.

Other Windows

The Properties Inspector displays the properties of an element, such as its value and description. Some of these properties may be changed.

The Show Children View window displays the sub-element, or first-level child, of a selected element.

The Find window is used to locate an element in the project view tree. Any element can be searched for by specifying a substring of its name or its type. The search can take place from the root, on the entire tree hierarchy, or from the selected element.

Configuring a ChorusOS Operating System Image

Open a Configuration File

The first operation is to open a ChorusOS configuration file (unless the -c option was used on the command line). For this, select the Open option in the File menu. A file selection dialog allows you to select the configuration file to open. The configuration to open is the conf/ChorusOS.xml file located in the configuration directory. Once opened, a new configuration item can be added to the navigation tree.

More than one configuration may be opened in Ews at the same time.

Browse the Configuration Tree

It is possible to browse the configuration by opening the elements in the navigation tree. There are two general kinds of elements in the tree: folders and variables. Folders are used to organize the configuration variables into hierarchical groups. A folder contains child elements that can be variables or folders. Variables are values used to configure the ChorusOS operating system image.

Disabled Elements

Some of the elements in the configuration tree may be grayed-out and cannot be edited. It is still possible to browse them, however. For example, some variables may depend on the presence of a specific feature: if this feature is not selected, and its current value is set to false, the corresponding tunables are disabled.

Disabling of elements in the configuration is controlled by a condition. This is an optional property attached to some elements, and if the condition is evaluated to false, the element is disabled (elements without a condition property are always enabled). If a folder is disabled, all its child elements (folders and variables) are also disabled.

Invalid Elements

A configuration is invalid if there are one or more invalid elements in the configuration tree.

Configuring the Features and Tunables

The features of the ChorusOS boolean variables, and tunables are expressed as either integers or enumerated variables. The following properties for a tunable are visible in the Properties Inspector:

• Name

• Type

• Default value

• Current value

To change the value of a tunable parameter, edit the Current value property.

Setting a ChorusOS Operating System Environment Variable

The values of the ChorusOS operating system image are located in the various Features and Tunables folders. Features expressed as ChorusOS operating system environment variables are contained in the env variable located in the Environment folder. The env variable is a list, where each element represents an environment variable. This list may be empty for a new configuration. It is possible to add, remove or modify environment variables stored in this list.

Adding an Environment Variable

Select the env variable, right-click to display its context menu, and select New Element. The newly created variable is appended to the list (you might need to expand the list to see the new variable). Set the value of the new variable by editing its value field.

Use makeroute to ensure that the paths to variables (plus actors and daemons) are correct. You can then easily add files to the system image using Ews by simply adding files in the application_files list.

Modifying the Value of an Environment Variable

An environment variable is a structured variable containing two fields: a name and a value. The name field stores the name of the environment variable, and the value field stores the value of this environment variable. Edit the value field to change the value of the environment variable.

Deleting an Environment Variable

From the context menu of the environment variable, choose Delete.

Saving the Modified Configuration

After a configuration has been edited, it can be saved. To do this, select the ChorusOS configuration item in the navigation tree (this is the root element of a configuration), and use its context menu. It is also possible to save it using the Save option in the File menu on the main menu bar, or the Save button on the toolbar.

A modified configuration is displayed in red, as a visual warning that the file has changed.

Build the system image, as described in "Rebuilding the System Image" .

Rebuilding the System Image

To rebuild the system image, select the ChorusOS configuration item in the navigation tree, and use the build item in its context menu (or the corresponding toolbar button). If the configuration file has not been saved since it was last modified, the tool will propose saving it, as the configuration must be saved to be built. If the configuration is invalid, it is not possible to build the corresponding ChorusOS operating system image. See "Invalid Elements".

During the build of the system image, various messages generated by the make tools are displayed in the Ews output window.

It is possible to interrupt the build using the stop button on the toolbar. In this case, the system image is not built.

Command-line Configuration Tool

The following sections explain how to use the command-line configuration tool, configurator, for some common tasks.

Displaying the Configuration

The configurator utility provides an option to display the ChorusOS operating system configuration in a web browser in HTML. Within your build directory, type the following command:

$ configurator -display /tmp/ChorusOS.html 

You can then use your browser to navigate through the ChorusOS.html file generated by this command.

Figure 2-2 Microkernel Configuration Displayed in HTML

Selecting a Configuration Profile

Two predefined profiles are provided, as described in "Configuration Files". To select the basic profile, type:

% configurator -p conf/basic

To re-select the extended (default) profile, type:

% configurator -p conf/extended

Adding, Removing, or Listing a Feature

You can use the configurator utility to add, remove, or list a feature.

Adding a Feature

To add a feature, type:

% configurator -set feature_name=true

The status of the feature_name is set to true.

For example, to add the EVENT feature to the default configuration:

% configurator -set EVENT=true

The configurator utility does not handle feature dependencies automatically. If you define an incomplete set of features, an error message is displayed.

Removing a Feature

To remove a feature, type:

% configurator -set feature_name=false

The status of the feature_name is set to false.

For example, to remove the EVENT feature:

% configurator -set EVENT=false 

You can reset the value of a feature to the default as follows:

% configurator -reset EVENT 

The reset command resets the value to the extended profile default.

Listing a Feature

You can check the value of a feature as follows:

% configurator -list features feature_name 

The output lists the feature and its status. If you omit feature_name, all features are displayed:

% configurator -list features

SEM:bool='true'
EVENT:bool='true'
RTMUTEX:bool='false'
TIMER:bool='true'
VTIMER:bool='false'
DATE:bool='true'

You can list a feature in greater detail with the -info option:

% configurator -info features feature_name 

The output lists the feature, its status, possible values and its description. For example:

% configurator -info features NFS_SERVER

NFS_SERVER:bool='false'
Possible values: true|false
Description: NFS server access from target machine

Changing Tunable Parameter Values

Tunable parameters are defined by symbolic names within the ChorusOS operating system components. Symbolic names include dots (.), to maintain compatibility with previous releases of the ChorusOS operating system. An example of a symbolic name is kern.exec.maxCpuNumber, which is a tunable.

The definition of a tunable parameter includes the definition of a default value for this parameter. Integer values of tunable parameters are expressed either as integers or as hexadecimal numbers.

To change the value of a tunable parameter, use:

% configurator -set tunable_name=value

For example, to reconfigure the microkernel to enable the creation of 300 threads:

% configurator -set kern.exec.maxThreadNumber=300

You can check the value of a tunable parameter as follows:

% configurator -list tunable tunable_name

You can list the values of all the microkernel executable tunables as follows:

% configurator -list tunable kern.exec.*

The output lists the microkernel executable tunables and their values:

kern.exec.maxCpuNumber:int='1'
kern.exec.maxActorNumber:int='64'
kern.exec.maxThreadNumber:int='300'
kern.exec.bgStackSiz:int='0x1000'
kern.exec.dflSysStackSize:int='0x3000'
kern.exec.dflUsrStackSize:int='0x4000'
kern.exec.dblFltStackSize:int='0x800'
kern.exec.intrStackSize:int='0x3000'

You can list a tunable parameter in greater detail with the -info option:

% configurator -info tunable tunable_name 

The tunable, its value and its description are displayed:

% configurator -info tunable kern.lap.*

kern.lap.maxLapBindNumber:int='256'
Description: Maximum number of bind LAPs 

kern.lap.maxLapSafeNumber:int='128'
Description: Maximum number of safe LAPs

Modifying the System Environment

The system environment is defined by a set of dynamic parameters. The system environment is a set of name-value pairs, where name and value are character strings. Values for system environment variables can be obtained by the system and applications at runtime using the sysGetEnv(2K) system call.

To display all the system environment variables, type:

% configurator -list env

To set a new environment variable, or change its value:

% configurator -setenv envar=value

Here is an example:

% configurator -setenv MESSAGE='HelloWorld'  

To unset a variable, so that it is removed from the environment, type:

% configurator -resetenv envar

Rebuilding the System Image

After you have finished modifying the configuration, rebuild the system image by typing:

% make chorus