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.
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 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.
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.
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.
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.
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).
At system start-up,
the C_INIT
actor executes these steps:
Sets up an initial virtual file system.
Executes commands from the configuration file sysadm.ini.
Executes commands from /etc/rc.chorus when a root file system is mounted (see C_INIT(1M)).
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.
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 |
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_DUMP
UtilityThis 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).
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.
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.
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.
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.
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.
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.
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.
extended
and basic
configuration profilesTable 2-2 C_INIT Feature Settings and Input Output Manager Feature settings in the
extended
and basic
configuration
profilesName | extended profile value | basic profile value |
|
---|---|---|---|
C_INIT features | |||
RSH | true | false | |
LOCAL_CONSOLE | false | true | |
Input Output Manager features | |||
IOM_IPC | false | false | |
IOM_OSI | false | false | |
DEV_MEM | true | false | |
DEV_CDROM | true | true | |
DEV_DISK | true | true | |
DEV_NVRAM | true | true | |
RAM_DISK | true | true | |
SCSI_DISK | false | false | |
FLASH | true | true | |
RAWFLASH | true | true | |
OS_GAUGES | false | false | |
VTTY | false | false | |
WDT | false | false | |
FIFOFS | true | false | |
FS_MAPPER | false | false | |
MSDOSFS | true | true | |
UFS | false | false | |
ISOFS | true | true | |
NFS_CLIENT | true | false | |
NFS_SERVER | false | false | |
ACTOR_SRCDBG | true | true | |
GZ_FILE | true | false | |
CORE_DUMP | false | false | |
IOM_DEV_MNGT | true | true | |
POSIX_MQ | false | false | |
POSIX_SHM | true | false | |
AF_LOCAL | true | true | |
BPF | true | false | |
POSIX_SOCKETS | true | true | |
PPP | false | false | |
SLIP | false | false | |
IPv6 | false | false | |
POSIX_REALTIME_SIGNALS | true | true | |
SOLARIS_SYSEVENT | false | false | |
HOT_RESTART | false | false | |
DRV_MERGE | false | false | |
DEBUG_SYSTEM | true | true | |
EDB_MONITOR | false | false |
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 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 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".
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".
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.
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.
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 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 |
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.
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.
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.
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.
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.
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.
A configuration is invalid if there are one or more invalid elements in the configuration tree.
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.
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.
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.
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.
From the context menu of the environment variable, choose Delete.
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" .
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.
The following sections explain how to use the command-line configuration tool, configurator, for some common tasks.
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.
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 |
You can use the configurator utility to add, remove, or list 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.
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.
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 |
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 |
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 |
After you have finished modifying the configuration, rebuild the system image by typing:
% make chorus |