The ChorusOS operating system provides an environment for applications running on a network of target machines, controlled by a remote host.
The target system runs the ChorusOS operating system and provides the execution environment.
The host machine provides the development and debugging environment. The user can develop the applications on the host and, from the host, start and debug these applications on the targets.
Services provided by the ChorusOS operating system are accessed as C routines. C header files provide the required constants, types and prototypes definitions. As the ChorusOS operating system is highly modular, header files reflect this modularity. However, in the following examples a global header file, named chorus.h, which collects most of the required header files, has been used for simplicity. Please refer to the man pages to get the actual minimum header file required for each service.
Most ChorusOS operating system constants start with K_. ChorusOS operating system error codes start with K_E. Constants and error codes are all written in uppercase.
Most specific data types are prefixed by Kn. When type names are composed of several lexems, the first letter of each lexem is written in uppercase while other letters are in lowercase, as in KnRgnDesc (region descriptor).
In order to compile and link an application, the following information is needed:
The header files and compilation flags
The program entry point
The libraries to be linked with the program according to the services used by the application, the environment present on the target system, and the actor type (user or supervisor)
In order to initialize the libraries correctly before starting the execution of the application code, the program entry point must be set to _start. After the initialization of libraries is completed, _start calls the _main routine which initializes variables in C++ programs. The main() routine is then called.
The _main routine manages any double calling at program initialization; some C++ compilers force a call to _main at the beginning of main().
Depending on the development system, it may be necessary to use specific linker directives to force the linker to extract the _start and _main routines from the libraries.
In order to choose which ChorusOS operating system libraries to use, the following points need to be considered:
Which APIs are used by the application program. For example, a program using the mathematical API has to be linked with the libm.a library.
What type of system is running on the target. For example, the librpc.a library cannot be used if you are using the basic environment and no additional features.
The address space in which the program will execute. For example a program loaded as a user extended actor must be linked with the libcx.a library.
As supervisor actors share the same supervisor address space, they are built as relocatable binaries, leaving the choice of the final link addresses to either the system configuration utility building the system image (for the basic environment) or the Actor Manager (for the extended environment).
Care must be taken when programming supervisor actors: no memory protection is provided between supervisor actors. A badly written supervisor actor accessing addresses outside its own address space can corrupt any supervisor region and cause unexpected behavior such as a system crash or reboot.
User actors are also built as relocatable binaries, even though they use private address spaces. The link address of the user actors and the size of the user address space are board dependent. For a given board, all user actors are linked at the same address.
The final link is done by the Actor Manager when actors are loaded dynamically on the target.