Processes

The ChorusOS operating system offers the following process management services:

• Memory Management

• Time Management

• Trace Management

• Environment Variables

• Private Data

• Password Management

Memory Management

The ChorusOS operating system offers various services which enable an actor to extend its address space dynamically by allocating memory regions. An actor may also shrink its address space by freeing memory regions. The ChorusOS operating system offers the possibility of sharing an area of memory between two or more actors, regardless of whether these actors are user or supervisor actors. There are three memory management models, MEM_FLAT, MEM_PROTECTED, and MEM_VIRTUAL (see "Memory Management Models" for details on memory management models).

---

Note -

For some reference target boards, the ChorusOS operating system does not implement all memory management models. For example, the ChorusOS operating system for UltraSPARC IIi-based boards does not implement the MEM_VIRTUAL model.

---

Basic Concepts

Each memory management module provides semantics for subsets or variants of these concepts. These semantics and variants are introduced, but are not covered in detail, in the following sections.

Address Spaces

The address space of a processor is split into two subsets: the supervisor address space and the user address space. A separate user address space is associated with each user actor. The address space of an actor is also called the memory context of the actor.

A memory management module supports several different user address spaces, and performs memory context switches when required in thread scheduling.

The supervisor address space is shared by every actor, but is only accessible to threads running with the supervisor privilege level. The microkernel code and data are located in the supervisor address space.

In addition, some privileged actors, that is, supervisor actors, also use the supervisor address space. No user address space is allocated to supervisor actors.

Regions

The address space is divided into non-overlapping regions. A region is a contiguous range of logical memory addresses, to which certain attributes are associated, such as access rights. Regions can be created and destroyed dynamically by threads. Within the limits of the protection rules, a region can be created remotely in an actor other than the thread's home actor.

Protections

Regions can be created with a set of access rights or protections.

The virtual pages that constitute a memory region can be protected against certain types of accesses. Protection modes are machine-dependent, but most architectures provide at least read-write and read-only. Any attempt to violate the protections triggers a page fault. The application can provide its own page fault handler.

Protections can be set independently for sub-regions inside a source region. In this case, the source region is split into several new regions. Similarly, when two contiguous regions get the same protections, they are merged into one region. The programmer is warned that abusing this module could result in consuming too many of the microkernel resources associated with regions.

Memory Management Models

The model used is determined by the settings of the VIRTUAL_ADDRESS_SPACE and ON_DEMAND_PAGING features. See the MEM(5FEA) man page for details.

Flat memory (MEM_FLAT)

The microkernel and all applications run in one unique, unprotected address space. This module provides simple memory allocation services.

The flat memory module, MEM_FLAT, is suited for systems that do not have a memory management unit (MMU), or when use of the memory management unit is required for reasons of efficiency only.

Virtual addresses match physical addresses directly. Applications cannot allocate more memory than is physically available.

Address Spaces

A unique supervisor address space, matching the physical address space, is featured. Any actor can access any part of physically mapped memory, such as ROM, memory mapped I/O, or anywhere in RAM.

On a given site, memory objects can be shared by several actors. Sharing of fractions of one memory object is not available.

At region creation time, the memory object is either allocated from free physical RAM memory or shared from the memory object of another region.

The concept of sharing of memory objects is provided to control the freeing of physical memory. The memory object associated with a region is returned to the pool of free memory when the associated region is removed from its last context. This concept of sharing does not prevent an actor from accessing any part of the physically mapped memory.

Regions

The context of an actor is a collection of non-overlapping regions. The microkernel associates a linear buffer of physical memory to each region, consisting of a memory object. The memory object and the region have the same address and size.

It is not possible to wait for memory at the moment of creation of a region. The memory object must be obtainable immediately, either by sharing or by allocating free physical memory.

Protections

There is no default protection mechanism.

Protected Memory (MEM_PROTECTED)

The protected memory module (MEM_PROTECTED) is suited to systems with memory management, address translation, and where the application programs are able to benefit from the flexibility and protection offered by separate address spaces. Unlike the full virtual memory management module (MEM_VIRTUAL), it is not directly possible to use secondary storage to emulate more memory than is physically available. This module is primarily targeted at critical and non-critical real-time applications, where memory protection is mandatory, and where low-priority access to secondary storage is kept simple.

Protected memory management supports multiple address spaces and region sharing between different address spaces. However, no external segments are defined; for example, swap and on-demand paging are not supported. Access to programs or data stored on secondary devices, such as video RAM and memory-mapped I/O, must be handled by application-specific file servers.

Regions

The microkernel associates a set of physical pages with each region. This set of physical pages is called a memory object.

At the moment of creation of the region, the memory object is either allocated from free physical memory or shared with the memory object of another region. Sharing has a semantic of physical sharing.

At the moment of creation of the region, you can initialize a region from another region. This initialization has a semantic of physical allocation and copying memory at region creation time. To keep the MEM_PROTECTED module small, no deferred on-demand paging technique is used. An actor region maps a memory object to a given virtual address, with the associated access rights.

The size of a memory object is equal to the size of the associated region(s).

It is not possible to wait for memory at region-creation time. The memory object must be obtainable immediately, either by sharing or by allocating free physical memory.

Protections

Violations of memory protection trigger memory fault exceptions that can be handled at the application level by supervisor actors.

For typical real-time applications, memory faults denote a software error that should be logged properly for offline analysis. It should also trigger an application-designed fault recovery procedure.

Virtual memory (MEM_VIRTUAL)

The virtual memory module, MEM_VIRTUAL, is suitable for systems with page-based memory management units and where the application programs need a high-level virtual memory management system to handle memory requirements greater than the amount of physical memory available. It supports full virtual memory, including the ability to swap memory in and out on secondary devices such as video RAM and memory-mapped I/O. The main functionalities are:

• Support of multiple, protected address spaces.

• On systems with secondary storage (the usual case), applications can use much more virtual memory than the memory physically available. This module supports full virtual memory with swapping in and out on secondary devices. This module is designed specifically to implement distributed UNIX subsystems on top of the microkernel.

• Pages are automatically swapped in and out when appropriate.

Segments

The segment is the unit of representation of information in the system.

Segments are usually located in secondary storage. The segment can be persistent (for example, files), or temporary, with a lifetime tied to that of an actor or a thread (for example, swap objects).

The microkernel itself implements special forms of segment, such as the memory objects that are allocated along with the regions.

Like actors, segments are designated by capabilities.

Regions

An actor region maps a portion of a segment to a given virtual address with the associated access rights.

The memory management provides the mapping between regions inside an actor and segments (for example, files, swap objects, and shared memory).

The segments and the regions can be created and destroyed dynamically by threads. Within the limits of the protection rules, a region can be created remotely in an actor other than the requesting actor.

Often, regions can define portions of segments that do or do not overlap. Different actors can share a segment. Segments can thus be shared across the network.

The microkernel also implements optimized region copying (copy -on-write).

Protections

Regions can be created with a set of access rights or protections.

The virtual pages constituting a memory region can be protected against certain types of access. An attempt to violate the protections triggers a page fault. The application can provide its own page fault handler.

Protections can be set independently for sub-regions inside a source region. In this case, the source region is split into several new regions. Similarly, when two contiguous regions get the same protections, they are combined into one region.

---

Note -

Abusing the MEM_VIRTUAL module could result in consuming too many of the microkernel resources associated with regions.

---

Explicit access to a segment

Memory management also allows explicit access to segments (namely, copying) without mapping them into an address space. Object consistency is thus guaranteed during concurrent accesses on a given site. The same cache management mechanism is used for segments representing program text and data, and files accessed by conventional read/write instructions.

Optional Memory Management Features

The ChorusOS operating system offers the following optional memory management features:

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.

Non-Volatile Memory (NVRAM)

The NVRAM feature provides a raw interface to non-volatile memory devices, such as /dev/knvram and /dev/nvramX.

The NVRAM feature does not itself export an API.

Memory Management API

The memory management API is summarized in the following table:

Function	Description	Flat	Protected	Virtual
rgnAllocate()	Allocate a region	+	+	+
rgnDup()	Duplicate an address space		+	+
rgnFree()	Free a region	+	+	+
rgnInit()	Allocate a region initialized from a segment			+
rgnInitFromActor()	Allocate a region initialized from another region		+	+
rgnMap()	Create a region and map it to a segment			+
rgnMapFromActor()	Allocate a region mapping another region	+	+	+
rgnSetInherit()	Set inheritance options for a region			+
rgnSetPaging()	Set paging options for a region			+
rgnSetProtect()	Set protection options for a region	+	+	+
rgnStat()	Get statistics of a region	+	+	+
svCopyIn()	Byte copy from user address space	+	+	+
svCopyInString()	String copy to user address space	+	+	+
svCopyOut()	Byte to user address space	+	+	+
svPagesAllocate()	Supervisor address space page allocator	+	+	+
svPagesFree()	Free memory allocated by svPagesAllocate()	+	+	+
svPhysAlloc()	Physical memory page allocator	+	+	+
svPhysFree()	Free memory allocated by svPhysAlloc()	+	+	+
svPhysMap()	Map a physical address to the supervisor space	+	+	+
svPhysUnMap()	Destroy a mapping created by svPhysMap()	+	+	+
svMemMap()	Map a physical address to the supervisor space	+	+	+
svMemUnMap()	Destroy a mapping created by svMemUnMap()	+	+	+
vmCopy()	Copy data between address spaces	+	+	+
vmFree()	Free physical memory			+
vmLock()	Lock virtual memory in physical memory			+
vmMapToPhys()	Map a physical address to a virtual address		+	+
vmPageSize()	Get the page or block size	+	+	+
vmPhysAddr()	Get a physical address for a virtual address	+	+	+
vmSetPar()	Set the memory management parameters			+
vmUnLock()	Unlock virtual memory from physical memory			+

Time Management

The ChorusOS operating system provides the following time management features:

• General interval timing

• Virtual timer

• Time of day (universal time)

• Real-time Clock

• Watchdog timer

• Benchmark timing

• High resolution timing

The interrupt-level timing feature is always available and provides a traditional, one-shot, timeout service. Time-outs and the timeout 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.

General Interval Timer (TIMER)

The TIMER feature implements a high-level timer service for both user and supervisor actors. One-shot and periodic timers are provided, with timeout notification via the execution of a user-provided upcall function by a handler thread in the application actor. Handler threads can invoke any microkernel or subsystem system call. This service is implemented using the TIMEOUT feature.

The extended timer facility uses the concept of a timer object in the actor environment. Timers are created and deleted dynamically. Once created, they are addressed by a local identifier in the context of their owning actor, and are deleted automatically when that actor terminates. Timer objects provide a naming mechanism and a locus of control for timing activities. All high-level timer operations, for example, setting, modifying, querying, or canceling pending timeouts, refer to timer objects. Timer objects are also involved in coordination with the threads used to execute application-level notification handlers.

Applications will typically use extended timer functions via a standard application-level library (see "POSIX Timers (POSIX-TIMERS)"). Timer handler threads are created and managed by this library. The library is expected to preallocate stack area for the notification functions, create the thread, and initialize the thread's priority, per-thread data, and all other aspects of its execution context, using standard system calls. The thread then declares itself available for execution of the tier notification (timerThreadPoolWait(2K)) system call to wait for the first or next relevant timeout event. Event arrival will cause the thread to return from the system call, at which point the library code can call the application's handler. The thread pool interface is designed to allow one or a small number of handler threads to service an arbitrary number of timers. An application can thus create a large number of handlers without the expense of a dedicated handler thread for each one.

At most, a single notification will be active for a given timer at any point in time. If no handler thread is available when the timer interval expires, either because the notification function is still executing from a previous expiration or because the handler thread(s) is(are) occupied executing notifications for other timers, an overrun occurs. When a handler thread becomes available (namely, re-executes timerThreadPoolWait()), it will return immediately and the notification function can be invoked immediately. At return from timerThreadPoolWait(), an overrun count is delivered to the thread. An overrun count value pertains to a particular execution of the notification function. The overrun count is defined as the number of timer expirations that have occurred since the preceding invocation of the notifying function without a handler thread being available. Thus for a periodic timer, an overrun count equal to one indicates that the current invocation was delayed, but by less than the period interval.

For details, see the TIMER(5FEA) man page.

TIMER API

The general interval timer (TIMER) API is summarized in the following table:

Function	Description
timerThreadPoolInit()	Initialize a thread pool
timerThreadPoolWait()	Wait for timer events
timerCreate()	Create a timer
timerDelete()	Delete a timer
timerGetRes()	Get timer resolution
timerSet()	Set a timer

Virtual Timer (VTIMER)

The VTIMER feature is responsible for all functions pertaining to measurement and timing of thread execution. It exports a number of functions that are used typically by higher-level operating system subsystems, such as, UNIX.

VTIMER functions include thread accounting (threadTimes(2K)) and virtual timeouts (svVirtualTimeoutSet(2K) and svVirtualTimeoutCancel(2K)). A virtual timeout handler is entered as soon as the designated thread or threads have consumed the specified amount of execution time. Virtual timeouts can be set either on individual threads, for support of subsystem-level virtual timers (for example, SVR4, setitimer, VIRTUAL, and PROF timers), or on entire actors, for support of process CPU limits.

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

Execution time accounting can be limited to execution in the thread's home actor (internal execution time), or can include cross-actor invocations such as system calls (total execution time).

The svThreadVirtualTimeout() and svThreadActorTimeout() handlers are invoked at thread level and thus can use any API service, including blocking system calls. Timeout events are delivered to application threads, such as threadAbort(), that is, a thread executes a virtual time handler on its own behalf.

For details about virtual time, see the VTIMER(5FEA) man page

VTIMER API

The virtual time API is summarized in the following table:

Function	Description
svActorVirtualTimeoutCancel()	Cancel an actor virtual timeout
svActorVirtualTimeoutSet()	Set an actor virtual timeout
svThreadVirtualTimeoutCancel()	Cancel a thread virtual timeout
svThreadVirtualTimeoutSet()	Set a thread virtual timeout
svVirtualTimeoutCancel()	Cancel a virtual timeout
svVirtualTimeoutSet()	Set a virtual timeout
threadTimes()	Get thread execution times
virtualTimeGetRes()	Get virtual time resolution

Time of Day (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 microkernel.

For details, see the DATE(5FEA) man page.

DATE API

The DATE API is summarized in the following table:

Function	Description
univTime()	Get time of day
univTimeAdjust()	Adjust time of day
univTimeGetRes()	Get time of day resolution
univTimeSet()	Set time of day

Date Management

ChorusOS 5.0 provides time and date management services that comply to Time Zone and Day Light Saving Time behaviors.

Date Management API

The date management utilities and API is summarized in the following table:

Function	Description
date()	Print or/and set the date
settimeoftheday()	System call to set the time of the day
gettimeoftheday()	System call to get the time of the day
adjtime()	System call to adjust the time of the day smoothly (used by the Network Time Protocol, NTP)
ctime()	Returns time argument as local time in ASCII string
localtime()	Returns time argument as local time in a structure
gmtime()	Returns time argument without local adjustment
asctime()	Returns ASCII time from time structure argument
mktime()	Returns time value from time structure argument
strftime()	Format printf like time from structure argument
tzset()	Set time zone information for time conversion routines

Real-Time Clock (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 details, see the RTC(5FEA) man page.

Watchdog Timer (WDT)

The watchdog timer feature enables a two-step watchdog mechanism on hardware. It consists of a lower-level system layer provided by the driver, that exposes a DDI, and a higher-level layer that hides the DDI and provides an easier API for any user program. The watchdog itself has two steps:

The interrupt step:

If the watchdog is not patted within a certain delay, an interrupt handler provided by the system is invoked. This interrupt handler attempts to shut down the system and to perform a system dump of the node to collect evidence of the problem.

The reset step:

If the interrupt step gets stuck or lasts too long, the watchdog resets the board, causing it to reboot.

The watchdog is either started by the system at system initialization or possibly by the boot loader. It is expected that a dedicated user-level process will be responsible for patting the watchdog throughout the normal life of the system. A failure in the patting process will lead to the interrupt step of the watchdog mechanism.

To cope gracefully with transitions at initialization time, as well as at system shut-down time, the system is designed to pat the watchdog by itself for a configurable amount of time at system initialization and system shut down. During these periods, where a patting process in user mode might not be possible, the system will play that role implicitly. However, the duration of these initialization and shut-down periods is bound to system configurable values, so it is impossible for initialization to reach the point where the user-level patting process begins without the watchdog interrupt occurring. Similarly, shut down is guaranteed to be bound, or the watchdog interrupt will occur.

Some hardware can support more than one watchdog. The API copes with such situations by associating handles to watchdogs. The WDT feature API is similar to the watchdog API for the Solaris operating environment.

For details on watchdog timer, see the WDT(5FEA) man page.

WDT API

The watchdog timer API is summarized in the following table:

Function	Description
wdt_pat()	Pat (reload) the watchdog timer
wdt_alloc()	Allocate a watchdog timer
wdt_realloc()	Reallocate a watchdog timer
wdt_free()	Disarm and free a watchdog timer
wdt_get_maxinterval()	Get the maximum limit (hardware) of a watchdog
wdt_set_interval()	Set the interval duration of a watchdog
wdt_get_interval()	Get the interval duration of a watchdog
wdt_arm()	Arm a watchdog
wdt_disarm()	Disarm a watchdog
wdt_is_armed()	Check whether a watchdog is armed
wdt_startup_commit()	Tells the system the initialiazation phase is over
wdt_shutdown()	Tells the system to start patting for shut down

---

Note -

The wdt_realloc() function enables a process to regain control over a watchdog allocated by a possibly dead process.

---

Benchmark Timing (PERF)

The benchmark timing (PERF) feature provides a very precise measurement of short events. It is used primarily for performance benchmarking.

The PERF API closely follows that of the TIMER feature.

For details, see the PERF(5FEA) man page.

High Resolution Timing

The high resolution timer feature provides access to a fine-grained counter source for applications. This counter is used for functions such as fine-grained ordering of events in a node, measurements of short segments of code and fault-detection mechanisms between nodes.

The high resolution timer has a resolution better than or equal to one microsecond, and does not roll over more than once per day.

High Resolution Timer API

The high resolution timer API is summarized in the following table:

Function	Description
hrTimerValue()	Get the current value of the fine-grained timer in ticks
hrTimerFrequency()	Get the frequency of the fine-grained timer in Hertz
hrTimerPeriod()	Get the difference between the minimum and the maximum of the possible values of the fine-grained timer in ticks

Trace Management

Trace management in the ChorusOS operating system is provided by the logging, black box, system dump, and core dump features.

Logging (LOG and syslog)

The LOG feature provides support for logging traces into a circular buffer on a target system. This feature has always been present in the ChorusOS operating system, and is retained for backward-compatibility reasons. A new, richer service called BLACKBOX has been introduced and has its equivalent in the Solaris operating environment (see "Black Box (BLACKBOX)").

The higher layers of the system also support a POSIX syslog facility. This service enables applications to write records that are marked with one of the possible predefined tags and a severity level. The records are sent to a syslog daemon that processes them according to a configuration file. Configuration of the daemon allows filtering of the records based on their tags and priority, and either appends them to a file, or sends them to a remote site. Records can also be ignored and discarded.

For details, see the LOG(5FEA) man page.

Logging API

The logging API is summarized in the following table:

Function	Description
sysLog()	Log a message in the circular buffer of the microkernel
vsyslog()	Write a log record (variable argument list)
openlog()	Open the log channel setting a default tag
closelog()	Close the log channel
setlogmask()	Set the priority mask level

In addition to the API, some other commands are provided:

Command	Description
syslogd	Daemon managing filtering and storing
logger	Write a message in a log
syslogd.conf	Configuration file for syslogd

Black Box (BLACKBOX)

The BLACKBOX feature provides an enhanced means for tracing and can be configured into or out of the system independently of the LOG feature.

The black box feature relies on multiple in-memory circular buffers that are managed by the system. One circular buffer is active at any time, which means that traces are added sequentially to that buffer. The buffer then wraps around when full. A buffer can be frozen through an explicit request indicating to the system which other buffer will be activated next. Records can be read from a frozen black box. Filtering control routines enables black box records to be discarded without the producer of such traces knowing about this filtering. Black box buffers are always part of the system dump in the case of a node failure leading to a dump.

The ChorusOS black box feature closely resembles the black box feature of the the Solaris operating environment.

For details, see BLACKBOX(5FEA).

Black Box API

The black box API common with the Solaris operating environment is summarized in the following table:

Function	Description
bb_event()	Write a record in the current black box
bb_freeze()	Freeze the current black box
bb_list()	Get the list and status of system black boxes
bb_open()	Open a frozen black box
bb_read()	Read the content of an open black box
bb_close()	Close an open black box
bb_release()	Unfreeze a frozen black box
bb_getfilters()	Retrieve current filters
bb_setfilters()	Set filters
bb_getseverity()	Retrieve severity level filter
bb_setseverity()	Set severity level filter
bb_getprodids()	Retrieve producer ID filter list
bb_setprodids()	Set producer ID filter list

The ChorusOS microkernel-specific API for BLACKBOX is as follows:

Function	Description
bbEvent()	Adds an event to the black box
bbFreeze()	Freezes the currently active black box and directs all future events to another black box
bbRelease()	Frees up a frozen black box
bbSeverity()	Gets and/or sets the global severity bitmap for the node
bbGetNbb()	Gets the number of black boxes configured on the node
bbList()	Gives information about the set of black boxes on the node
bbFilters()	Gets and/or sets the filter list and the filtered severity bitmap for the node
bbProdids()	Gets and/or sets the list of producers that have been registered to use the filter list and the filtered severity bitmap on this node
bbOpen()	Obtains access to a frozen black box
bbClose()	Releases access to a frozen black box
bbReset()	Resets a frozen black box
bbName()	Gets and/or sets the symbolic name of a persistent store used to hold the given black box

System Dump (SYSTEM_DUMP)

The system dump feature enables the system to collect data in case of a crash. In the ChorusOS operating system, data collection is defined as the content of the black box buffers. On system crash, these data are copied to a persistent memory area, or dump area, which is based on the HOT_RESTART feature of the ChorusOS operating system. The system is then hot-restarted so that the persistent memory area is preserved. This reboot operation gives control back to the ChorusOS bootMonitor, which initiates the transfer of collected data to a configurable local or remote location. Remote transfer is based on the TFTP protocol.

For details, see the SYSTEM_DUMP(5FEA) man page.

System Dump API

The SYSTEM_DUMP API is summarized in the following table:

Function	Description
systemDumpCopy()	Copy the black box and system information in the dump area
systemDumpTransfer()	Transfer the dump area to the storage location

Core Dump (CORE_DUMP)

The core dump feature allows offline, postmortem analysis of actors or processes that are killed by exceptions. This is performed in three steps:

• Gathering the relevant information from the actor or process to be killed

• Dumping the information into a core file on a stable storage medium

• Reloading the core file on the host machine for analysis

The core file is generated in the case of a fatal exception, upon request from the debugging server or agent or upon request from any actor or process. The following information is collected in the core file:

• The current threads and their characteristics, namely, all hardware and software registers, the scheduling characteristics, and the thread's name and ID

• The actor or process name, ID, capability, and type

• Dynamic and shared library informations, such as path names and relocation information

• Memory regions in use

For details, see the CORE_DUMP(5FEA) man page.

Environment Variables (ENV)

The ChorusOS environment variables (ENV) provide users and applications the ability to define configuration parameters at various stages of system construction and operation, for example at boot and run time. They also allow applications to get the values of these parameters at run time. These dynamic configuration parameters take the form of a string environment, namely, a set of string pairs (name, value).

For details, see the ENV(5FEA) man page.

Environment Variable API

The ENV API is summarized in the following table:

Function	Description
sysGetEnv()	Get a value.
sysSetEnv()	Set a value
sysUnsetEnv()	Delete a value

Private Data (PRIVATE-DATA)

The PRIVATE-DATA API implements a high-level interface for management of private per-thread data in the actor address space. It also provides a per-actor data service for supervisor actors only. This service is complemented by POSIX libraries, that are defined in the POSIX-THREADS(5FEA) feature, for example pthread_key_create(3POSIX) and pthread_setspecific(3POSIX).

For details, see the PRIVATE-DATA(5FEA) man page.

Private Data API

The PRIVATE-DATA API is summarized in the following table:

Function	Description
padGet()	Return actor-specific value associated with key
padKeyCreate()	Create an actor private key
padKeyDelete()	Delete an actor private key
padSet()	Set actor key-specific value
ptdErrnoAddr()	Return thread-specific errno address
ptdGet()	Return thread-specific value associated with key
ptdKeyCreate()	Create a thread-specific data key
ptdKeyDelete()	Delete a thread-specific data key
ptdRemoteGet()	Return a thread-specific data value for another thread
ptdRemoteSet()	Set a thread-specific data value for another thread
ptdSet()	Set a thread-specific value
ptdThreadDelete()	Delete all thread-specific values and call destructors
ptdThreadId()	Return the thread ID

Password Management

The bases for password management in the ChorusOS operating system are the classical /etc/master.passwd and /etc/group files. The ChorusOS operating system provides regular routines to access these files. These databases can be supported by either local files, NIS, or LDAP.

For details of password management, see the ChorusOS 5.0 System Administrator's Guide.

Password Management API

The password management API is summarized in the following table:

Function	Description
ldap.conf()	LDAP configuration file
getpwuid()	Password database operation
getgrent()	Group database operation
getgrgid()	Group database operation
getgrnam()	Group database operation
setgroupent()	Group database operation
setgrent()	Group database operation
endgrent()	Group database operation
getpwent()	Group database operation
getpwnam()	Group database operation
getpwuid()	Group database operation
setpassent()	Group database operation
setpwent()	Group database operation
endpwent()	Group database operation
getusershell()	Password database operation
pwd_mkdb()	Generate password databases
passwd()	Modify a user's password
group()	Format of the group permissions file