You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initialization entry priorities (along with levels, but let's not consider it here for simplification) are meant to sort which entry has to start before/after another one. Such entries can be about a device instance or a "software" instance (SYS_INIT(...)).
Most device instances are DTS based, and the priority is thus inferred from DTS directly. However this is not the case for SYS_INIT(...) instances. This creates a weird half-way backed system where users still may have to tweak manually the priority numbers, either in code or via Kconfig when possible, to get a proper initialization entries ordering.
All of this should be automated. There is no reason not to. Also taking into account that:
It should also keep the possibility to instantiate a device out of DTS (manual instantiation)
deprecation of existing macros should go along properly. I.e. these macros should not break during that time (only the priority parameter might have to be tweaked on some instances to keep a sane ordering.)
It should enable the possibility of adding new features related to initialization entries without changing the new macros
Solution
Following a proposal #73836 and following discussions, here are the steps to full-fill:
Find new macro names that will be used to replace the ones that are going to be deprecated: SYS_INIT but also all DEVICE_DEFINE_* ones (since priority parameter is going to disappear)
Current problem
Initialization entry priorities (along with levels, but let's not consider it here for simplification) are meant to sort which entry has to start before/after another one. Such entries can be about a device instance or a "software" instance (SYS_INIT(...)).
Most device instances are DTS based, and the priority is thus inferred from DTS directly. However this is not the case for SYS_INIT(...) instances. This creates a weird half-way backed system where users still may have to tweak manually the priority numbers, either in code or via Kconfig when possible, to get a proper initialization entries ordering.
All of this should be automated. There is no reason not to. Also taking into account that:
Solution
Following a proposal #73836 and following discussions, here are the steps to full-fill:
The text was updated successfully, but these errors were encountered: