Friedrich-Alexander-Universität UnivisSearch FAU-Logo
Techn. Fakultšt Willkommen am Department Informatik FAU-Logo
Logo I4
Department of Computer Science 4
  Hello World: First Steps
  Raw Memory Access
  Inter-Domain Comm.
  Service Protection
  CiAO backend
  core module API

CiAO backend
Dept. of Computer Science  >  CS 4  >  Research  >  KESO  >  Documentation  >  CiAO backend
KESO's CiAO backend

This howto highlights some pecularities of KESO's CiAO backend. Since CiAO is currently not publicly available, this information is mostly directed at local students.


The toolchain used to run KESO on top of CiAO may seem somewhat complicated at the first glance, but allows to combine C and Java components in one application and also to easily choose from alternate Java and C implementations if available. In the following, we will go through the steps involved in building a KESO application for CiAO.

CiAO backend toolchain

The above figure shows the toolchain that combines KESO and CiAO. A CiAO system is normally built in two steps:
  1. Configure the OS and create the variant.
  2. Build the created variant.
KESO hooks into the process after step 1. The Java code parts are added to created CiAO variant which already contains the C components' code (if any) and the code of the OS. In the example the name of the application is demo, which appears in some of the shown path names.


The CiAO build system expects the $CIAOBASE environment variable to contain the path name of the root directory of your CiAO installation. This is the directory that contains amongst others the subdirectories kconf and os.

Configuring and creating the CiAO variant

A CiAO application normally resides in an own directory under the $CIAOBASE/os/app/ directory. Besides the code files of C components, this directory should contain (for the standard build variant, demo should be replaced by the respective application name):
  • Makefile: Targets for configuring OS and application
  • Targets for building the variant. Becomes Makefile in the created variant.
  • Application feature model. Should at least include the feature models for the HAL of the chosen target architecture and the OS. May define additional features that are configurable for the application itself.
  • Familiy model for the application. Defines the actions to take for the application specific features.
  • Configuration of the configuration process. Defines things such as the feature model and family models to use, the target architecture and the output directory.
  • Template for OS object instances for the current application. Defines which tasks, applications, etc. exist. The properties of the actual instances are configured in the kconf frontend.
To start a new application, you can create a new application directory from a template using

$ cd $CIAOBASE/os/app $ ./ --variant keso demo

Linux kconfig is used for configuring the CiAO OS and the operating system level objects. For KESO, the application specific part need not be specified in kconfig, since it is automatically taken from the $KESORC file. You can invoke a GUI frontend by running the following command from the application directory:

$ make xconfig

This will creates/updates the configuration file demo.config. To create the CiAO variant run the following command from the application directory:

$ make transform

By default, the variant will be created to the directory $CIAOBASE/kconf/config, with your application code in $CIAOBASE/kconf/config/app/demo.

Adding KESO source parts to the CiAO variant

The code of the Java components is added to the created CiAO variant. The steps are principally the same as described in the generic toolchain, with the following percularities:
  • When using the CiAO backend, the World block in the $KESORC file needs to be named Keso, and the System block needs to be named the same as the CiAO application directory, i.e. demo in our example.
  • The output directory for jino needs to be modified to generate the code to the directory where the created CiAO variant resides. This is done by setting the $KESOOUTPATH environment variable:

    $ export KESOOUTPATH=$CIAOBASE/kconf/config/app/demo

jino's output files will then reside in a subdirectory Keso_demo of the CiAO, which is where the default build files for CiAO expect them. Most notably, when using KESO components the family model used in the CiAO application must not generate the config.xml but instead generate a symlink to Keso_demo/config.xml. The default build files in existing CiAO applications with KESO components already do that.

Compiling the CiAO OS and the Applications

The last step is do compile the source code of the applications and the CiAO OS. This is done by just running make in the variant's directory:

$ cd $CIAOBASE/kconf/config/app/demo $ make

This should produce a binary image demo.elf in that directory.

  Imprint   Privacy Last modified: 2011-01-19 16:42   MS