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
Zephyr doesn't have a consistent ABI like most platforms that Rust targets. Rust interfaces with the C calling convention, which is stable, but the set of functions exported by the kernel depends on the kernel config for each project. zephyr-rust uses kconfig to ensure required kernel features, like an allocator, are enabled. Major kernel config options like CONFIG_USERSPACE also currently influence how Rust binaries are built. Additionally, the Zephyr API is not particularly stable across versions.
For upstreaming Zephyr support to libstd, can we require Zephyr source (and final project config) to be present during the build, or should we try to build binaries independently? Building completely independent binaries would require defining a stable interface to link against. That might be out of the scope of this project and might not fit the optimization goals of Zephyr.
Building Rust in the same CMake environment as the kernel seems best for Zephyr integration, but I don't know if that is compatible with upstream Rust's expectations for building libstd. Maybe environment variables like ZEPHYR_BASE and something to point to the project could loosely couple the two without requiring cargo to be invoked from within CMake.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Zephyr doesn't have a consistent ABI like most platforms that Rust targets. Rust interfaces with the C calling convention, which is stable, but the set of functions exported by the kernel depends on the kernel config for each project. zephyr-rust uses kconfig to ensure required kernel features, like an allocator, are enabled. Major kernel config options like CONFIG_USERSPACE also currently influence how Rust binaries are built. Additionally, the Zephyr API is not particularly stable across versions.
For upstreaming Zephyr support to libstd, can we require Zephyr source (and final project config) to be present during the build, or should we try to build binaries independently? Building completely independent binaries would require defining a stable interface to link against. That might be out of the scope of this project and might not fit the optimization goals of Zephyr.
Building Rust in the same CMake environment as the kernel seems best for Zephyr integration, but I don't know if that is compatible with upstream Rust's expectations for building libstd. Maybe environment variables like ZEPHYR_BASE and something to point to the project could loosely couple the two without requiring cargo to be invoked from within CMake.
Beta Was this translation helpful? Give feedback.
All reactions