This changes platforms.Parse to hit /proc to look up CPU info only when
it's needed, instead of in init(). This makes the package a bit easier
for other packages to consume, especially clients that don't call
platforms.Parse or need to lookup CPU info.
Signed-off-by: Jason Hall <jasonhall@redhat.com>
`OnlyStrict()` returns a match comparer for a single platform.
Unlike `Only()`, `OnlyStrict()` does not match sub platforms.
So, "arm/vN" will not match "arm/vM" where M < N, and "amd64" will not also match "386".
`OnlyStrict()` matches non-canonical forms. So, "arm64" matches "arm/64/v8".
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
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 <admwiggin@gmail.com>
This improves the hard-coded list of ARM fallbacks in the `platform.Only` implementation (by doing a descending loop over variant numbers instead, which is all the hard-coded list was doing).
Making this a separate function can then more easily be recursive later for handling an `arm64`->`arm` fallback (or similar), but I think it makes the code a lot more clear too (so we're calculating a vector of platforms separately from building a matcher object).
This also makes a minor adjustment in `TestImagePullWithDistSourceLabel` which had an implicit assumption that `platforms.Only` would only ever result in a single suitable manifest, which isn't strictly true (and is likely failing as-is when run on any 32bit `arm` system that's `v6` or higher, which this fixes 😅).
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
On the very popular Raspberry Pi 1 and Zero devices, the CPU is actually ARMv6, but the chip happens to support the feature bit the kernel uses to differentiate v6/v7, so it gets reported as "CPU architecture: 7" and thus fails to run many of the images that get pulled.
To account for this very popular edge case, this also checks "model name" which on these chips will begin with "ARMv6-compatible" -- we could also check uname, but getCPUInfo is already handy, low overhead, and mirrors the code before this.
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Don't rely on /proc/cpuinfo denoting a 64-bit ARMv8 processor if the
runtime detected GOARCH == arm. This allows aarch64 32-bit userspace
distros to run containers properly via a 32-bit runtime.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
arm has been supported, but something is missing, causes test failure
--- FAIL: TestParseSelector/linux (0.00s)
platforms_test.go:292: arm support not fully implemented: not implemented
--- FAIL: TestParseSelector/macOS (0.00s)
platforms_test.go:292: arm support not fully implemented: not implemented
Signed-off-by: Shengjing Zhu <zhsj@debian.org>
This commit improves ARM platform matching in two instances:
* Some old kernels reported the CPU architecture of arm64 cpus as
Aarch64 [1].
* In cases where the user is running with armv8 cpu and kernel but amrhf
user land (so armhf containerd), a possibility given the compatibility
of armv8 with armv7.
[1] https://elixir.bootlin.com/linux/v3.14.29/source/arch/arm64/kernel/setup.c#L420
Signed-off-by: Jaime Caamaño Ruiz <jcaamano@suse.com>
ARM variant detection logic was authored originally with
POSIX OS in mind. This change leaves POSIX code path unaltered
and adds support to detect ARM variant on Windows by leveraging
runtime.goarch.
Signed-off-by: Jiri Appl <jiria@microsoft.com>
Implements the Windows lcow differ/snapshotter responsible for managing
the creation and lifetime of lcow containers on Windows.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
Adds a new platform interface for matching and comparing platforms.
This new interface allows both filtering and ordering of platforms
to support running multiple platform and choosing the best platform.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
This function is analogous to `regexp.MustCompile` and can simplify production
of a `Platform` from a hard-coded strings, e.g. for global variable
initialisation.
Signed-off-by: Ian Campbell <ian.campbell@docker.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>
This test case should cover the variant field now, as we have
add Variant to default value of spec.platform.
Change-Id: I8359007d40a4b8f6a072510fff2ba604a062afa1
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Signed-off-by: Penny Zheng <Penny.Zheng@arm.com>
The variant is required for platform match while pulling images
for ARM platforms. Currently, the cpuVariant only would be assigned
on linux/arm|arm64 platforms. Other platforms this variable would
be empty. So we can use this cpuVariant to initialize the Variant
field.
Change-Id: Ic065be9b502f1e662445daa61a0973bf56385b37
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Signed-off-by: Penny Zheng <Penny.Zheng@arm.com>
In the commit "26329b2b8d7fd4e290b2b0f0163547f2d79bb817",
dmcgowan/fix-pull-multi-arch, PR#1535. The containerd has enabled the pull
multi-arch image support. But the platform.variant field of OCI for ARM
hadn't been ready at that time, so all ARM images could not pull successfully.
"
docker.io/library/hello-world:latest:
resolved |++++++++++++++++++++++++++++++++++++++|
index-sha256:3644c0788e3d3823f9e97f757f01d2ddc6eb5458df9d801:
done |++++++++++++++++++++++++++++++++++++++|
elapsed: 5.1 s
total: 2.7 Ki (533.0 B/s)
unpacking sha256:3d3823f9e97f757f01d2ddc6eb5458df9d801...
ctr: : manifest not found: not found
"
In this patch we'll detect the ARM variants from /proc/cpuinfo. Because Linux
kernel has already detected the ABI, ISA and Features for us. We don't need to
parse them from registers again.
Change-Id: I479b34bf3f52df9f7a6b3c77718b7d316dbf7f69
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Signed-off-by: Penny Zheng <Penny.Zheng@arm.com>
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>
Matching support is now implemented in the platforms package. The
`Parse` function now returns a matcher object that can be used to
match OCI platform specifications. We define this as an interface to
allow the creation of helpers oriented around platform selection.
Signed-off-by: Stephen J Day <stephen.day@docker.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>
