Module config

Data structure for storing compile-time configuration options in the kernel.

The rationale for configuration based on a const object is twofold.

• In theory, Cargo features could be used for boolean-based configuration. However, these features are generally error-prone for non-trivial use cases. First, they are globally enabled as long as a dependency relationship requires a feature (even for other dependency relationships that do not want the feature). Second, code gated by a non-enabled feature isn’t even type-checked by the compiler, and therefore we can end up with broken features due to refactoring code (if these features aren’t tested during the refactoring), or to incompatible feature combinations.

• Cargo features can only contain bits. On the other hand, a constant value can contain arbitrary types, which allow configuration based on integers, strings, or even more complex values.

With a typed const configuration, all code paths are type-checked by the compiler - even those that end up disabled - which greatly reduces the risks of breaking a feature or combination of features because they are disabled in tests.

In the meantime, after type-checking, the compiler can optimize away dead code by folding constants throughout the code, so for example a boolean condition used in an if block will in principle have a zero cost on the resulting binary - as if a Cargo feature was used instead. Some simple experiments on generated Tock code have confirmed this zero cost in practice.

Structs

• Config
  Data structure holding compile-time configuration options.
• IfElseCfg
  These types are for situations where a feature would change what type is in use. This is better than conditional compilation as a single compilation run can type check all combinations of features.

Enums

• CfgConsumed
• CfgMatch
• CfgMatchMut

Constants

• CONFIG
  A unique instance of Config where compile-time configuration options are defined.

Traits

• CfgControl
  Trait allows selecting type based on a const param