 | build 3.0.0.201402161939 |
| build 3.0.0.201402161939 |
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.
Allow additional control over the active state of this interface.
List the source files that should be built if this interface is active.
Specify additional #define symbols that should go into the owning package's configuration header file.
Control how the interface's value will appear in the configuration header file.
Use a fragment of Tcl code to output additional data to configuration header files.
Provide a textual description for this interface.
Provide a short string describing this interface.
The location of on-line documentation for this interface.
Interfaces have the data flavor by default, but they can also be given the bool or booldata flavor when necessary. A bool interface is disabled if there are no active and enabled implementors, otherwise it is enabled. A booldata interface is also disabled if there are no active and enabled implementors, otherwise it is enabled and the data is a number corresponding to the number of these implementors.
Output a common preprocessor construct to a configuration header file.
If this interface is active it provides one instance of a more general interface.
Interfaces always have a small numerical value. The legal_values can be used to apply additional constraints such as an upper limit.
An additional custom build step associated with this option, resulting in a target that should not go directly into a library.
An additional custom build step associated with this option, resulting in an object file that should go into a library.
Suppress the normal generation of a preprocessor #define symbol in a configuration header file.
Control the location of this option in the configuration hierarchy.
List constraints that the configuration should satisfy if this option is active and enabled.
A number of properties are not applicable to interfaces:
Interfaces are always calculated, based on the number of active and enabled entities that implement the interface.
Interface values are calculated so a default_value property would be meaningless.
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.