ChorusOS 4.0 Introduction

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:

Actor management
Scheduling
Memory management
Hot restart and persistent memory
Inter-thread communication
Time management
Inter-process communication
Local Access Point (LAP)
Tools support
C_INIT
File system options
I/O management
Networking
Administration

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 management	`ACTOR_EXTENDED _MNGT`
	User-mode extension support	`USER_MODE`
	Dynamic libraries	`DYNAMIC_LIB`
	Compressed file management	`GZ_FILE`
Scheduling
	POSIX round-robin scheduling class	`ROUND_ROBIN`
Memory management
	Virtual (user and supervisor) address space	`VIRTUAL_ADDRESS_ SPACE`
	On-demand paging	`ON_DEMAND_PAGING`
Hot restart and persistent memory
	Hot restart	`HOT_RESTART`
Inter-thread communication
	Semaphores	`SEM`
	Event flag sets	`EVENT`
	Mutual exclusion locks supporting thread priority inversion avoidance	`RTMUTEX`
Time management
	Periodic timers	`TIMER`
	Thread and actor virtual timer	`VTIMER`
	Date and time of day	`DATE`
	Real-time clock	`RTC`
Inter-process communication
	Location-transparent inter-process communication	`IPC`
	Remote (inter-site) IPC support	`IPC_REMOTE`
	Remote IPC communications medium	`IPC_REMOTE_COMM`
	Mailbox-based communications mechanism	`MIPC`
	POSIX 1-compliant message queues	`POSIX_MQ`
	POSIX 1-compliant shared memory objects	`POSIX_SHM`
LAP
	Local name server for LAP binding	`LAPBIND`
	LAP validity-check option	`LAPSAFE`
Tools support
	Message logging	`LOG`
	Profiling and benchmark support	`PERF`
	System monitoring	`MON`
	System debugging	`DEBUG_SYSTEM`
C_INIT
	Basic command interpreter on target	`LOCAL_CONSOLE`
	Remote shell	`RSH`
File system options
	Named pipes	`FIFOFS`
	NFS client	`NFS_CLIENT`
	NFS server	`NFS_SERVER`
	MS-DOS file system	`MSDOSFS`
	UFS file system	`UFS`
I/O management
	Network packet filter	`BPF`
	Swap support	`FS_MAPPER`
	Driver for IDE disk	`IDE_DISK`
	`/dev/mem`, `/dev/kmem`, `/dev/null`, `/dev/zero`	`DEV_MEM`
	Support for RAM disk	`RAM_DISK`
	Support for FLASH media	`FLASH`
	Virtual TTY	`VTTY`
	Driver for SCSI disk	`SCSI_DISK`
	Support for IPC	`IOM_IPC`
	Support for OSI	`IOM_OSI`
Networking
	Serial link IP	`SLIP`
	POSIX 1003.1g-compliant sockets	`POSIX_SOCKETS`
	Point-to-point protocols	`PPP`
	Local sockets and pipes	`AF_LOCAL`
Administration
	ChorusOS statistics	`ADMIN_CHORUSSTAT`
	`ifconfig` administration command	`ADMIN_IFCONFIG`
	`mount` administration command	`ADMIN_MOUNT`
	`rarp` administration command	`ADMIN_RARP`
	`route` administration command	`ADMIN_ROUTE`
	`shutdown` administration command	`ADMIN_SHUTDOWN`
	`netstat` administration command	`ADMIN_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:

Support for multiple independent applications
Support for user and system applications
Support for applications in user and supervisor address space
Dynamic memory management

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.

MEM_FLAT

This memory management model provides simple memory allocation services. The kernel and all applications run in one unique unprotected address space.
MEM_PROTECTED

This memory management model is targeted at real-time applications able to benefit from the flexibility and protection offered by memory management units, address translation and separate address spaces. No swap or demand paging is provided. No mapper interface is provided. Accesses to programs and data stored on secondary devices must be done by application-specific file servers.
MEM_VIRTUAL

This memory management model supports full virtual memory with swapping in and out on secondary devices. It has been specifically designed to implement distributed UNIX subsystems on top of the kernel.

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:

An actor restart mechanism which detects crashes in restartable actors, and automatically restarts them from an actor image in persistent memory.
Persistent memory allocation. Actors can allocate blocks of persistent memory to store data which will persist beyond the actor's lifetime.
A site restart mechanism to restart the kernel, boot actors and all restartable actors on a system without accessing stable storage.

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

The counter is decremented when a thread performs a P on a semaphore. If the counter reaches a negative value, the thread is blocked and put in the semaphore's queue, otherwise, the thread continues its execution normally.
The counter is incremented when a thread performs a V on a semaphore. If the counter is still lower than or equal to zero, one of the threads queued in the semaphore queue is picked up and awakened.

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:

Interrupt-level timing
General interval timing
Time of day (universal time)
System time
Thread execution timing
Benchmark timing

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:

Individual threads, to support subsystem-level timers.
Entire actors (that is, multiple threads), to support process CPU limits.

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 unit of communication (message)
Point-to-point communication endpoints (port)
Multi-cast communication endpoints (groups)

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:

A free-running mode, which causes the timer to overflow after reaching its maximum value and continue to count up from its minimum value. This mode can be used for fine grained execution measurement. This deactivates the system clock.
A periodic mode, where the system timer is shared between the application and the system tick. The timer will generate an interrupt at a set interval. The application handler will be invoked at the required period. This mode can be used by applications such as profilers.

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:

Network file system, NFS (client and server)
MS-DOS file system
UNIX file system, UFS

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:

SCSI disks
IDE disks
RAM disks

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