RFC: devicetree: use stable identifiers for LLEXT-exported DT object names

[pillo79]

Introduction

Zephyr extensions can directly interact with DT devices with the same rules of the Zephyr application, thanks to #78508. By their nature, llexts are not tied to the main application - ideally, they should be unrelated - but some details of the current Zephyr build system practically force them to be rebuilt whenever the main application changes.

This RFC addresses one specific aspect of this - stability of DeviceTree device identifiers between similar builds.

Problem statement

Currently Zephyr uses a simple but effective sequential numbering scheme for the various C identifiers associated with Devicetree nodes: each node is numbered incrementally and results in adts_ord_nnn name and C-level identifier. Since these numbers are allocated at every build, any node added or removed in the DT will result in a different mapping between identifiers and devices.

This is a problem for extensions that need to access devices and DT nodes, as these names would not be constant and the extension would have to be rebuilt along with the main application on any Devicetree change, even those not directly affecting the extension.

Proposed solution

This RFC proposes to add a Kconfig option, CONFIG_LLEXT_EXPORT_DEV_IDS_BY_HASH, to use a stable hash computed at build time from the full DT path of the node for the DT identifiers exported via LLEXT to exensions.

The switch is done at the Zephyr header level, so enabling this flag requires no further changes to either the Zephyr app or any extensions' sources (provided they all are built with the same setting).

Conclusion

Stable DT names, or some way to have a stable object look-up, is going to be important for LLEXT moving forward. Looking for feedback on both the proposed approach and implementation.

Detailed RFC

The existing dts_ord_* symbols are also referenced outside the build process, therefore to retain compatibility, the current symbols are left unchanged. Enabling CONFIG_LLEXT_EXPORT_DEV_IDS_BY_HASH only changes the LLEXT-exported names for these objects to an identifier of the form dts_xxx, with xxx being the base64-encoded SHA256 hash of the DT node (a 43-char string).

With 256-bit hashes of ASCII strings, a collision (two distinct strings causing the same hash) is an exceedingly unlikely event (~1E-77, see this comment for more details); still, this possibility is verified and the build fails if that is detected.

Proposed change (Detailed)

An implementation of this, including tests, is available in #77799.

Alternatives

Globally replacing the ordinal names with hashes is definitely a smaller source change, but with implications well outside the LLEXT subsystem.

[teburd]

Is this likely to mess up init ordering, I believe the ordinal is in part used for initialization sequencing?