Riot: Order of auto_init functions

[jue89]

Description

I am using a cryptoauthlib-compatible chip for a board I am working on. It features a user-programmable config zone, which holds the EUI-64 of the device.

I would like to use this as the source for luid_base() to bring the EUI-64 to the attached network interfaces.

I started implementing luid_base() by fetching the EUI-64 from the crypto chip on-the-fly. But after doing so RIOT isn't able to boot.

The problem is luid_base() gets called before the cryptoauthlib auto_init function has been executed resulting in a failed boot-up.

I was able to resolve this problem by reordering the auto_init. The old order:

• random
• xtimer
• cryptoauth

The new order:

• xtimer
• cryptoauth (requires xtimer)
• random (requires luid_base and, thus, cryptoauthlib in my case)

Is anyone else experiencing similar difficulties? Or am I using RIOT wrongly?

[benpicco]

I think what you really want is #12641
This unfortunately got stuck when it came to the right way to handle multiple netifs and multiple EUIs…

I have a branch where I started assigning unique (ascending) IDs to netifs so those can be used by board_get_eui64() - I should probably finish that.

[jue89]

Nice! This would resolve my conflict. The only remaining problem is that the netif auto_init functions are called before the cryptoauthlib auto_init function. Would it be an acceptable solution to reorder the auto_init functions?

[benpicco]

The order probably needs a cleanup - there is one ongoing already right now: #13542

[miri64]

The order probably needs a cleanup - there is one ongoing already right now: #13542

That one does _not_ reorder the function calls (and since it is already quite big and not very easy to track, I would prefer to do re-ordering in a separate PR).

[benpicco]

Yes, but if @jue89 wants to re-order something he should probably wait for this PR to go through first, otherwise a nasty merge conflict is guaranteed.