The eCos Component Writer's Guide
Prev |  | Next

# `cdl_interface`

## Name

Command `cdl_interface` — Define an interface, functionality that can be provided by a number of different implementations.

## Synopsis

    cdl_interface <name> {
        …
    }

## Description

An interface is a special type of calculated configuration option. It provides an abstraction mechanism that is often useful in CDL expressions. As an example, suppose that some package relies on the presence of code that implements the standard kernel scheduling interface. However the requirement is no more stringent than this, so the constraint can be satisfied by the mlqueue scheduler, the bitmap scheduler, or any additional schedulers that may get implemented in future. A first attempt at expressing the dependency might be:

        requires CYGSEM_KERNEL_SCHED_MLQUEUE || CYGSEM_KERNEL_SCHED_BITMAP

This constraint is limited, it may need to be changed if a new scheduler were to be added to the system. Interfaces provide a way of expressing more general relationships:

        requires CYGINT_KERNEL_SCHEDULER

The interface `CYGINT_KERNEL_SCHEDULER` is implemented by both the mlqueue and bitmap schedulers, and may be implemented by future schedulers as well. The value of an interface is the number of implementors that are active and enabled, so in a typical configuration only one scheduler will be in use and the value of the interface will be `1` . If all schedulers are disabled then the interface will have a value `0` and the requires constraint will not be satisfied.

Some component writers may prefer to use the first requires constraint on the grounds that the code will only have been tested with the mlqueue and bitmap schedulers and cannot be guaranteed to work with any new schedulers. Other component writers may take a more optimistic view and assume that their code will work with any scheduler until proven otherwise.

Interfaces must be defined in CDL scripts, just like options, components and packages. This involves the command `cdl_interface` which takes two arguments, a name and a body. The name must be a valid C preprocessor identifier: a sequence of upper or lower case letters, digits or underscores, starting with a non-digit character; identifiers beginning with an underscore should normally be avoided because they may clash with system packages or with identifiers reserved for use by the compiler. Within a single configuration, names must be unique. If a configuration contained two packages which defined the same entity `CYGIMP_SOME_OPTION` , any references to that entity in a requires property or any other expression would be ambiguous. It is possible for a given name to be used by two different packages if those packages should never be loaded into a single configuration. For example, architectural HAL packages are allowed to re-use names because a single configuration cannot target two different architectures. For a recommended naming convention see the section called Package Contents and Layout in Chapter 2 .

The second argument to `cdl_interface` is a body of properties, typically surrounded by braces so that the Tcl interpreter treats it as a single argument. This body will be processed by a recursive invocation of the Tcl interpreter, extended with additional commands for the various properties that are allowed inside a `cdl_interface` . The valid properties are a subset of those for a `cdl_option` .

active_if

  Allow additional control over the active state of this interface.

compile

  List the source files that should be built if this interface is active.

define

  Specify additional `#define` symbols that should go into the owning package's configuration header file.

define_format

  Control how the interface's value will appear in the configuration header file.

define_proc

  Use a fragment of Tcl code to output additional data to configuration header files.

description

  Provide a textual description for this interface.

display

  Provide a short string describing this interface.

doc

  The location of on-line documentation for this interface.

if_define

  Output a common preprocessor construct to a configuration header file.

implements

  If this interface is active it provides one instance of a more general interface.

legal_values

  Interfaces always have a small numerical value. The legal_values can be used to apply additional constraints such as an upper limit.

make

  An additional custom build step associated with this option, resulting in a target that should not go directly into a library.

make_object

  An additional custom build step associated with this option, resulting in an object file that should go into a library.

no_define

  Suppress the normal generation of a preprocessor `#define` symbol in a configuration header file.

parent

  Control the location of this option in the configuration hierarchy.

requires

  List constraints that the configuration should satisfy if this option is active and enabled.

A number of properties are not applicable to interfaces:

calculated

  Interfaces are always calculated, based on the number of active and enabled entities that implement the interface.

default_value

  Interface values are calculated so a default_value property would be meaningless.

flavor

  Interfaces always have the flavor `data` .

Interfaces are not containers, so they cannot hold other entities such as options or components.

A commonly used constraint on interface values takes the form:

        requires CYGINT_KERNEL_SCHEDULER == 1

This constraint specifies that there can be only one scheduler in the system. In some circumstances it is possible for the configuration tools to detect this pattern and act accordingly, so for example enabling the bitmap scheduler would automatically disable the mlqueue scheduler.

Interfaces always have the `data` flavor, so they are always enabled. Therefore any compile or other build-related properties will always take effect if the interface is active, even if the interface has a value of 0 because nothing implements it.

> Note: It is possible that the flavor of an interface may change to `booldata` in a future version of the configuration system. An interface with no active enabled implementors would have a value of `0` , which would result in the interface being disabled. This is analogous to the behavior of the default_value and calculated properties for other `booldata` entities. The implications of such a change are not yet well-understood, but it would have the advantage that interfaces could now be used as containers.

## Example

    cdl_interface CYGINT_KERNEL_SCHEDULER {
        display  "Number of schedulers in this configuration"
        requires 1 == CYGINT_KERNEL_SCHEDULER
    }

## See Also

Property implements , command `cdl_option` . command `cdl_component` , command `cdl_package` .

Prev | Home | Next
`cdl_package` | Up | active_if