Starting from Torizon Core 7.0, the configuration setting CONFIG_COMPAT=y, specified during the Linux kernel build, has been removed.
Consequently, this has prevented the execution of Docker image containers built for the 32-bit architecture, which used to work on Torizon Core 6.7.
Although the Linux kernel version 6.68 in Torizon Core 7 supports the execution of 32-bit binaries even in 64-bit architecture runtime environments, this removal has affected functionality.
By declaring CONFIG_COMPAT=y in layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex-6.6-2.2.x/nxp-imx.cfg, it has been confirmed that programs intended for 32-bit architecture can run in the iMX8QM runtime environment.
I have questions regarding the uncertainties:
1. I believe this change constitutes a feature alteration lacking backward compatibility (commonly known as Breaking Changes), yet I couldn’t find any mention in the release notes. If this change was intentional, it ought to be documented in the release notes.
Was this simply an oversight, or was the execution of programs specific to 32-bit architecture intentionally made unsupported? Please clarify.
2. Our project includes programs with libraries built for the 32-bit architecture, and therefore, support for the 32-bit architecture is essential.
If this setting is enabled, please inform us of any potential side effects, concerns, or points of verification that may come to mind.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
I don’t have specific information about the CONFIG_COMPAT=y kernel configuration change between Torizon OS 6.7 and 7.0 in the available sources. The documentation I have access to doesn’t cover this specific kernel configuration change or its impact on 32-bit container compatibility.
However, I can provide some relevant information about 32-bit container support. The documentation does mention that preliminary tests show it’s possible to run 32-bit containers on 64-bit platforms, though 64-bit versions are encouraged whenever possible(1).
For your specific questions about:
Breaking changes documentation - I don’t have access to the specific release notes that would detail this kernel configuration change
Side effects of enabling CONFIG_COMPAT=y - I don’t have documentation covering the potential impacts of this specific kernel configuration
Since this involves kernel-level configuration changes and potential breaking changes between major Torizon OS versions, I’d recommend checking the official Torizon OS 7.0 release notes and change logs for detailed information about this specific modification.
For immediate assistance with your 32-bit architecture requirements, you might want to explore these potentially useful resources:
Looking into this, I could not see an explicit reason for the removal of CONFIG_COMPAT going into Torizon OS 7.X.
For reference, the kernel configuration from Torizon OS comes in two parts. The majority of the configuration comes from the underlying Toradex BSP that Torizon OS is based on top of. This is the kernel configuration used for non-Torizon images like our BSP reference images. With Torizon OS we add additional configuration settings on top of this.
Looking at the history it seems back in 6.X this CONFIG_COMPAT came from the first set of configurations from the Toradex BSP: Making sure you're not a bot!
This configuration was inherited from the NXP kernel configuration which was used as a base for our configuration.
With 7.X instead of using a defconfig file we instead started to use a separate kernel configuration repository: Making sure you're not a bot!
Seems during the transition CONFIG_COMPAT wasn’t brought over. Though there wasn’t any explicit commits or comments that specifically excluded it. I’ll inquire internally if any of my colleagues happens to know. Though it may likely be the case that this configuration option was unintentionally left out.
All that said, just to understand. You’re 32-bit binaries on our Apalis i.MX8QM module correct? Is there a specific reason you use 32-bit binaries here rather than 64-bit?
The reason for running the 32-bit library on the Apalis IMX8QM is because that library is the C language library licensed from another company, and their official support is only available for a build of the 32-bit architecture. Previously, unexpected issues were discovered when executing the library in Docker images intended for the 64-bit architecture, which led to building Docker images for the 32-bit architecture as well.
If you know the circumstances behind the removal of CONFIG_COMPAT=y at your company, please let me know.
After discussing this with the team internally, it seems there was no specific reason this configuration was removed. I’ll go ahead and open a request to re-enable this configuration option in Torizon OS 7.X.
After some discussion the CONFIG_COMPAT option has been re-enabled in Torizon OS 7. To have access to this change you will need a recent nightly image of Torizon OS 7, starting from today forward. Though of course the next stable release of Torizon OS 7 should also include this option as well.
