[riot-notifications] [RIOT-OS/RIOT] Module initialization - tidyup (#11342)
notifications at github.com
Thu Apr 4 15:49:00 CEST 2019
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 https://github.com/RIOT-OS/RIOT/pull/9013#issuecomment-477687534
- 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: https://github.com/RIOT-OS/RIOT/pull/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.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications