sys: add auto_init includes treewide

[fjmolinas]

Contribution description

Current headers are only visible in the auto-init compile unit, make them visible whenever the module is used.

Testing procedure

green ci.

[benpicco]

I think this might be by design - which header do you need?

[fjmolinas]

I think this might be by design - which header do you need?

The auto_init_priorities.h If I want to use those defines out of the auto init compilation unit (e.g. defining an external auto-init with priority AUTO_INIT_PRIO_MOD_DUMMY_THREAD + 1

[benpicco]

Ah ok - but better move the file to sys/include then, maybe sys/include/auto_init/priorities.h?

[fabian18]

#define MY_MODULE_PRIO AUTO_INIT_PRIO_MOD_DUMMY_THREAD + 1

does not evaluate to a number because the preprocessor does not substitude the result.
You can look into the .map file of you compiled application and search for auto_init_xfa to see the result.
For your external module you would have to #define the actual computation result.

[fabian18]

Something which would work, would be concatenation, but then the numeric comparability would be broken, which was requested in the original PR

[fjmolinas]

UTO_INIT_PRIO_MOD_DUMMY_THRE

Huh, true, if I did AUTO_INIT_PRIO_MOD_DUMMY_THREAD - 1 I actually get an error right away... too bad

[fjmolinas]

UTO_INIT_PRIO_MOD_DUMMY_THRE

Huh, true, if I did AUTO_INIT_PRIO_MOD_DUMMY_THREAD - 1 I actually get an error right away... too bad

I do have a question regarding how to add or change priorities going forward? If I can't refer to the macro values, then I at some point there is a new module pushed earlier than lets say random all other modules will need to be bumped as well, and then my externally defined priority is meaningless, is there a better way to do this?

[fabian18]

hmm I´m sorry. I thought this was clear : /
We decided to keep it that simple and avoid macro hacking with concatenation.

[fabian18]

is there a better way to do this?

concatenation, something like this

#define AUTO_INIT_PRIO_AFTER(base, position) EVAL(base) ## position

#define MY_MODULE_PRIO AUTO_INIT_PRIO_AFTER(AUTO_INIT_PRIO_MOD_DUMMY_THREAD, 1)

or make the preprocessor do the math somehow.

[fabian18]

Just a kind of brute force idea: Have SUCCESSOR macros for a range of numbers [1010, 1550 ].
Quick and dirty untested, but the idea should be understandable:

#define SUCCESSOR_1070 1071

#define SUCCESSOR(x) SUCCESSOR_ ## EVAL(x)


#define MY_MODULE_PRIO SUCCESSOR(AUTO_INIT_PRIO_MOD_DUMMY_THREAD)

[fabian18]

This would be zero overhead, but many lines of code and a bit ugly.

[fabian18]

Maybe such a header could be auto-generated for a given range of numbers. Other modules could also profit from preprocessor +1 addition and -1 subtraction.

[fabian18]

https://www.boost.org/doc/libs/1_67_0/boost/preprocessor/arithmetic/inc.hpp

[fjmolinas]

https://www.boost.org/doc/libs/1_67_0/boost/preprocessor/arithmetic/inc.hpp

Yep, I was looking into those right now as well, does pre-procesor introduce a lot of overhead? I think we should think of two things:

• in tree maintainability: make it easy for us to move things up-down the priority queue
• external maintainability: make it easy for external users to keep track of how we assign priorities.

If the compilation overhead is OK, then we could use boost for everything, and define all priorities as relative to a base priority. so if inserting something in the queue you just have to re-tagg the priority just after it. That would mean zero code changes for an external user, an only a couple for us.

[fabian18]

does pre-procesor introduce a lot of overhead?

I think we would not even notice a difference in compilation times. But I have never experimented with it.

[fjmolinas]

does pre-procesor introduce a lot of overhead?

I think we would not even notice a difference in compilation times. But I have never experimented with it.

I think it would be worth the try, I'll put it on my todo list (although with low priority)