TF: Configuration Task Force status

[jia200x]

This issue contains the status and discussions about the recently opened RIOT Configuration Task Force.

There's a Configurations TF Project for organizing issues and PR.

Please link new issues/PR concerning configurations to this issue so we can easily get in sync.

Areas of concern

The following areas are being addressed by the CTF

Compile-time configuration

• Declare, define and expose build-time configurations in documentation ([CTF]: Compile-time configuration of components #10138)
• Expose configurations to Kconfig ([CTF-tracker] Kconfig: Configuration exposure list #12888)
• Model features provided by CPU and Boards (Tracker: Kconfig: Model features provided by CPU and Board #14148)

Archives

Minutes

RIOT summit breakout session (13/09/2018)

See comment below

RIOT Virtual Maintainer Assembly 2020.05

Usage of Kconfig for module dependency modelling. See discussion.

Proposals

Compile-time configuration proposal for RIOT (video)

Archived info

Initial draft

[jcarrano]

E.g CFLAGS += -DFF=default -DFF=new_value will fail.

I'd say that CFLAGS += -DFF=some_value -DFF=conflicting_val will not fail (at compile time), instead the value will be silently overwritten and that's the problem.

[jia200x]

I'd say that CFLAGS += -DFF=some_value -DFF=conflicting_val will not fail (at compile time), instead the value will be silently overwritten and that's the problem.

Addressed. Thanks!

[jia200x]

Here's a summary of the RIOT summit breakout session:

Minute

• The community identified the following problems:

  • Mixed build configuration and functionality (app) configuration
  • Overriding periph configuration: it's possible to copy&paste the board periph configuration in the application, but generates a lots of code duplication and doesn't allow overriding.
  • Everything gets recompiled when changing a configuration
  • App and hw configurations are not exposed, is hard to know what can be configured (specially for beginners).
  • There is unnecesary periph configuration for some application (e.g hello world only requires 1 UART, some boards configure 3)
  • Boards don't have human-readable names, sometimes is hard to remember the actual name of a board when flashing.
  • No standard mechanism to pass app data (keys, etc)
  • No standard mechanism to configure third party packages (lwip, openthread, etc).
  • There are no API versions nor modules versions, it's not easy to know if an application will work with a given RIOT version (and it's not possible to know if it's safe to update to a new RIOT release).
  • It's possible to inject arbitrary code if configurations are handled in Makefiles.

• The following solutions/concepts were proposed to address one or more of these problems

  • Cross file arrays (core: introduce crossfile arrays (xfa), refactored #9105 )
  • High level parsers for detecting invalid configurations and modules
    • YAML (or similar) for describing dependencies and valid configuration params
  • Human Readable CLI make arguments
  • Linux tools: KConfig
  • Fetch other repositories (e.g core repo, utils repo, etc)
  • Declare configurations in header files
  • Configurations should be close to the module (so, it's easy to get rid)
  • Whatever we do, we still need to consider third party pkgs have their own configuration mechanism, which should be invoked from RIOT.

Check the original post-its based minute here. @leandrolanzieri did a nice transcription here

You can watch the full session via Youtube

Outcome

We agreed on start with per-module config declaration (macros) in header files:

• It's non intrusive
• This approach could solve some of the issues exposed by the community (declare configurations, define default values, override configurations) E.g see off-line email from @kaspar030

/**
 * @brief maximum number of cooks per soup
 *
 * fmt:int:min=1:max=10
 */
#ifndef CONFIG_KITCHEN_MAX_COOKS_PER_SOUP
#define CONFIG_KITCHEN_MAX_COOKS_PER_SOUP 1U
#endif

A tool could parse and expose these configurations to the user.

We can always add later something on top for handling third party PKGs configurations (that have their own configuration scheme), friendly GUIs (ncurses, web based, etc) and handling dependencies and invalid cofigurations.

[MrKevinWeiss]

We can close this I suppose...