General Principles

When writing applications for ChorusOS systems, there are certain principles and conventions you should be aware of. These are described in the following sections.

Programming Conventions

The ChorusOS operating system provides a large variety of services that you can use in your applications. These services are accessed as C routines. C header files provide the required constants, types, and prototype definitions. The high modularity of the ChorusOS operating system is reflected by the numerous header files. However, in the following examples a global header file, named chorus.h, is used for simplicity. The chorus.h header file collects most of the required header files. Refer to the man pages to obtain the actual minimum header files required for each service.

Most ChorusOS operating system constants are prefixed with K_. ChorusOS operating system error codes are prefixed with 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 lexemes, the first letter of each lexeme is written in uppercase while the remaining letters are in lowercase, as in KnRgnDesc (region descriptor).

To compile and link an application, the following information must be specified in the makefile:

• The header file directories and compilation flags.

• The program entry point.

• The libraries to be linked to the program according to the services used by the:

  • Application

  • Environment present on the target system

  • Actor type (user or supervisor)

Program Entry Point

To initialize libraries correctly before starting the execution of application code, the program entry point must be set to _start. Once 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.

Libraries

To determine which ChorusOS operating system libraries to use, consider the following points:

• Which APIs (POSIX or microkernel) are to be used by the application.

• What additional libraries are required.

• In which address space will the application execute.

Supervisor Application Binaries

Because supervisor applications share the same supervisor address space, they are built as relocatable binaries which are linked dynamically prior to loading. Supervisor applications jump into the system to access system services, that is, they do not trap.

When programming supervisor applications, remember that no memory protection is provided between applications. A badly written supervisor application that accesses addresses outside its own address space can corrupt any supervisor region and cause unexpected behavior such as a system crash or reboot.

User Application Binaries

Although user applications use private address spaces, they are also built as relocatable binaries. This simplifies the building of supervisor and user applications. Unlike supervisor applications, user applications trap to the system to access system services.

User applications built as relocatable binaries can run in either VIRTUAL_ADDRESS_SPACE or in non-virtual address space (flat memory). If they were relocated on the host, these binaries cannot run in flat memory mode, which does not support private address spaces.

Although it is possible to relocate user applications on the host, the ChorusOS operating system provides no specific tools to achieve this.

The link address (relocatable) of the user applications and the size of the user address space are board-dependent. User applications are also linked dynamically prior to loading.