When images/containers in ARM arch were built/executed on x86 host,
getCPUVariant will fail as it tries to look for /proc/cpuinfo, whose
content is from the host. Adding a new method as fallback to check uname
machine when it happens.
Signed-off-by: Tony Fang <nenghui.fang@gmail.com>
Correctly matches optional variants for amd64
arch. These should be used for standardized values
v1-v4 from https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels.
V1 remains the default and is cleared by default.
Pulling a higher variant will match the highest
available platform lower or equal to the provided one
when platformVector is used.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
The normalization was being inconsistently applied causing a
failure to match some platforms in manifest lists.
Fix the matcher and normalization to be more consistent and
add changes to parser to prevent the defaulted variants from being
set in the platform structure.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
On ARM platforms, we have to prepare the variant for spec.platform.
Currently, this action would only work on Linux/ARM system. We
introduce these two helpers to check running system's OS and Arch.
Change-Id: Iff14087699219413779dd6caf1bf9524db1cc19e
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
For supporting selection of images and runtimes in the containerized
world, there is thin support for selecting objects by platform. This
package defines a syntax to display to users that can express specific
platforms in addition to wild cards for matching platforms.
The plan is to extend this to provide support for parsing flag
arguments and displaying platform types for images. This package will
also provide a configurable matcher to allow match of platforms against
arbitrary targets, invariant to the Go compilation.
The internals are based the OCI Image Spec model.
This changeset is being submitted for feedback on the approach before
this gets larger. Specifically, review the unit tests and raise any
concerns.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
