Allow arm64 to fallback to arm (v8, v7, v6, v5)#4932
Allow arm64 to fallback to arm (v8, v7, v6, v5)#4932fuweid merged 1 commit intocontainerd:masterfrom
Conversation
|
That's a suspiciously large number of failures. 😬 |
|
Build succeeded.
|
|
Oh. https://github.com/containerd/containerd/actions/runs/480924253 (appears to be the same failure on the latest Maybe not my fault? 😅 |
|
@tianon rebase might fix the issue 😂 |
This isn't supported by *all* arm64 chips, but it is common enough that I think it's worth an explicit fallback. I think it will be more common for images to have arm64 support without arm support, but even if a user has an arm64 chip that does not support arm32, having it fail to run the arm32 image is an acceptable compromise (because it's non-trivial to detect arm32 support without running a binary, AFAIK). Also, before this change the failure would've simply been "no such image" instead of "failed to run" so I think it's pretty reasonable to allow it to try the additional 32bit set of images just in case one of them actually does work (like it will on many popular chips like 64bit Raspberry Pis and AWS Graviton). Signed-off-by: Tianon Gravi <[email protected]>
tianon
force-pushed
the
arm64-fallback
branch
from
832ce94 to
4073aaa
Compare
|
Build succeeded.
|
|
Hm... late to the party, but it came up in a discussion;
Apparently, Apple's m1 falls in the category "not all arm64 chips", and doesn't support 32 bit 😞 |
|
My understanding is that fallback is not a requirement for chipmakers and if it isn't then we shouldn't make up our own rules that give wrong behavior to users. If other more modern chips start coming out I'd expect them to also start dropping the support. All future Apple chips will definitely not support this. If we want to have some magic that detects the chips where fallback is possible and it can be determined from |
|
The end result is |
|
Docker Desktop in M1 can run arm32 containers, but they run under qemu emulator like other unsupported architectures(no run error). But to do that user needs to use flags that opt-in to emulation mode and ignore the warnings. If they set their expected platform as arm64 then they don't get something else running under emulation. |
|
Generally i think automatic fallback to 32 bit architectures is a mistake in containerd, it is not what people mostly want. The client could ask for it, but there are potential security issues (lack of workable ASLR), compatibility issues (I was downloading a container to use libraries in it in build and 32 bit ones won't link), and performance issues if it runs under emulation, or doesn't run at all. |
6 participants
This isn't supported by all arm64 chips, but it is common enough that I think it's worth an explicit fallback. I think it will be more common for images to have arm64 support without arm support, but even if a user has an arm64 chip that does not support arm32, having it fail to run the arm32 image is an acceptable compromise (because it's non-trivial to detect arm32 support without running a binary, AFAIK).
Also, before this change the failure would've simply been "no such image" instead of "failed to run" so I think it's pretty reasonable to allow it to try the additional 32bit set of images just in case one of them actually does work (like it will on many popular chips like 64bit Raspberry Pis and AWS Graviton).
This also reverts #4013 (#3990) because it should no longer be necessary with this follow-up to #4891 - if
GOARCHisarmbut the CPU reports variant 8, it will try 8, then 7, 6, and finally 5, andarm64will fall back to that same vector.The exact set of "acceptable" platforms is more clearly seen in the test changes. 😄 😏