Replies: 2 comments 2 replies
-
I remember there was some talk about this on FOSDEM, but not sure where the actual specification landed after that ? https://archive.fosdem.org/2020/schedule/event/archspec/ But it (archspec) knew about the different microarchitectures: https://archspec.readthedocs.io/en/latest/microarchitectures.html |
Beta Was this translation helpful? Give feedback.
-
Thanks for reaching out, @dcermak! The OCI image specification defines a platform as a triple of architecture, OS and variant. The ARM platforms commonly fall under "variant". I assume that the same can be done in case of x86_64 (amd64 in OCI terms). You can find the "platform matcher code" of Podman here. It could very well be extended for amd64. CRI-O, Skopeo, Buildah and Podman would automatically support it by vendoring c/image. But similar changes had to be done for other tools, notably containerd and Docker. To the best of my knowledge, all current implementations would just select the first amd64 image and ignore the variant. Variants are usually only checked for ARM. It's probably worth reaching out to the OCI image-spec maintainers by opening an issue and/or joining one of their weekly meetings. |
Beta Was this translation helpful? Give feedback.
-
Multiple Linux distributions are currently moving their x86_64 baseline from x86_64 v1 to v2 or even v3, which brings up an interesting problem for containers: afaik there is no support for x86_64 sub-architectures like there is e.g. for arm (arm32v7, arm32v6, arm64v7, etc. the difference here is that these are truly different architectures, whereas x86_64 sub-architectures are just a defined subset of the full instruction set for x86_64).
It would be nice to eventually support something like this in podman (and the wider container ecosystem directly), so that container authors could build images for x86_64 v1, v2 & v3 and podman would pull the image for your specific CPU (or when in doubt v1).
There is of course the option to workaround this by using tags like
my-image:1.5-x86_64v1
,my-image:1.5-x86_64v2
etc, but that carries its own set of downsides.Any ideas how this could be implemented or whether this even should be implemented at all? And how to coordinate this with the wider container ecosystem, so that also docker, nerdctl and kubernetes support this?
Beta Was this translation helpful? Give feedback.
All reactions