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.
The above figure shows the toolchain that combines KESO and CiAO.
A CiAO system is normally built in two steps:
Configure the OS and create the variant.
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.
Environment
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
Makefile.app: Targets for building the variant. Becomes Makefile in the created variant.
demo.fm: 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.
demo.cmp.pl: Familiy model for the application. Defines the actions to take for the application specific features.
demo.configspace.pl: Configuration of the configuration process. Defines things such as the feature model and family models to use, the target architecture and the output directory.
demo.profile.pl: 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
$ ./create_app.pl --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:
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.