Module initialization - tidyup

[danpetry]

Description

This issue aims to address some problems we have recently seen related to module initialization.

Current state

The current state of initialization of modules in RIOT is as follows. This description is basically design-level rather than implementation-level - in other words, it doesn't take into account implementations that deviate from our normal way of doing things.

• low level peripherals (i.e. modules below the HAL) are initialized in either boards/ or cpu/ depending on whether they're board-specific or cpu-specific
• all modules above the HAL that are compiled into the binary are initialised in sys/auto_init, in the order defined there
• modules required explicitly in a particular tests/ or applications/ are initialised there

The last two points mean that modules can often be initialized twice.

Problems seen

Some problems related to this area are as follows:

• if a module depends on another module being initialised, all modules currently have to be initialized by calling auto_init. This is a problem when testing, for various reasons related to the idea that it doesn't allow you to isolate functional operation to that specific module. For example, you may not want your module to be automatically initialized, because you might want to test corner cases related to e.g. erroneous initialization by a user. See board: add hamilton board support #9013 (comment)
• the initialization for all modules currently happens in one central module. This has several problems related to the idea that it breaks encapsulation of modules. For example, multiple contributions often involve simultaneous changes to auto_init.c, which makes maintaining that module difficult and couples development between otherwise unrelated contributions, including resolving merge conflicts etc. Current efforts to solve this involve being able to share arrays, potentially containing initialization function pointers, between compilation units: core: introduce crossfile arrays (xfa), refactored #9105
• It's not currently a contribution requirement for initialization functions to be idempotent (and be tested as so). This could lead to difficult-to-identify bugs
• Initialization functions may have a hard requirement to be called one after another. Currently this is expressed in auto_init, but not explicitly, meaning contributors could unknowingly break things through changes in order (for example, to handle their own startup dependencies, etc).

Idea for way forward

Suggestion is that we refine the two sections above until we feel that we understand (and agree on) the problem fully before moving on to finding a comprehensive design solution.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.