platform.arch != GOARCH

[mattspencer-arm]

I would like to make one last plea to the community to consider not deferring definition of the values of platform.arch to GOARCH, but instead hold a canonical list of accepted values within this specification.

The reason is that runtime requirements for an image need not be tied to any runtime capabilities of golang. I can give a concrete example here of ARM's ILP32 ABI which is currently in the process of reviewed by the community for upstreaming.

We currently have no need or desire to add ILP32 capability to golang. The host platform will be running in 64 bit only mode. So there will be no 'arm64ilp32' definition in GOARCH. This does not mean that a container image can't be compiled against the ILP32 ABI, and be run on a platform that has a container engine built in arm64 mode, but also have the runtime capability for ILP32.

We have validated this in the offices here with a docker engine running in LP64/arm64 mode, whist executing a container image compiled against the ILP32 ABI.

The current OCI scheme does not seem to allow for me to define this runtime requirement.

I would therefor like to suggest that the OCI specification holds the canonical list for platform.arch.

[vbatts]

understandable.

https://github.com/opencontainers/runtime-spec/blob/master/config.md#platform does not have a MUST around this though.

         If an architecture is not included in the GOARCH documentation, it SHOULD be submitted to this specification for standardization.

This does not prevent putting in the value of arm64ilp32. It would be up to runtime whether they "support" this arch.

As for having a canonical list, something like this use-case you've provided could be the first to add here. Should we have a table just below the example for Platform?

[wking]

See also the in-flight #850, where the platform information will become entirely internal and we'll drop the architecture component completely.

[vbatts]

@stevvooe says -->
https://docs.google.com/document/d/1zgRBe9rpvogFEotmhxqpjrPdeaIDaIfD0ox-wvwe6nI/edit
https://golang.org/src/go/build/syslist.go
https://groups.google.com/a/opencontainers.org/forum/m/#!topic/dev/Eht-i5UbUvo
arm64ilp32 would be arm64p32

[stevvooe]

@mattspencer-arm As I've mentioned before, OCI shouldn't really be in the business of maintaining a curated list of platform and architectures. We don't have the resources or expertise to get it right. We have deferred to GOARCH because the Go team have this as a first-class problem and have done a good job of defining a taxonomy of extant hardware while avoiding the explosion of gnu triples.

As far as an "example", ilp32 is more of an exception, and the only exception. Taking on the extra definitions and forking the definitions for what amounts to a single exception is very unwise. It is incumbent on the ARM team to reach out and request at least an architecture identifier from the Go team before OCI takes on the expense of a fork. It seems reasonable that they would at least reserve it for a future port.

Furthermore, if the only container platforms that are running arm64ilp32 are actually just arm64 systems and the pointer size is detectable in the ELF, presumably, I am not sure that I understand the necessity of calling this out directly. When container runtimes do exist that are targeted for ilp32, and nothing else, it seems that would be a good time to differentiate.

[mattspencer-arm]

@vbatts The naming convention as set out by the go syslist would be arm64p32, but the correct naming would be arm64ilp32 as it is the ilp32 ABI that is being used.

@stevvooe I understand the reasons why the OCI have deferred this difficult problem over to another organisation. And there does seem to be a precedent for putting 'placeholders' into the syslist definition - I am not aware of anyone using arm64be for example, but it exists in the list. So this could be a viable solution for us.

/However/

My worry is that the metadata here is going to be embedded in many thousands of packages in hundreds of image repositories and there is no specification control over the nomenclature. What if the go community decide to change the way they express GOARCH? How would that impact the container community?

I would not suggest starting again with a new definition of the architecture. What I would suggest is that the OCI specification takes a snapshot of the GOARCH definition as it stands today and then curates any modifications to the base GOARCH definition to control any impact it may have on live container ecosystems.

[stevvooe]

@mattspencer-arm Why should we do this when the only exception is ARM? It makes no sense to take on that amount of complexity and effort when all that needs to be done is reach out to the Go team and ask them for an architecture identifier for your new platform.

Right now, we have a single platform with an exception that it is not represented in GOARCH, which is solvable with much less effort than creating a new architecture tautology.

What if the go community decide to change the way they express GOARCH? How would that impact the container community?

If they do that, we will solve that problem at that time. As it stands now, GOARCH is both sufficient and complete.

Reach out to the golang-dev mailing list and ask them for an identifier for arm64p32. If you don't want to do it, I'll do it.

[wking]

Obsolete now that #850 has landed?

[mattspencer-arm]

I think we can close this - I wouldn't say its obsolete, because the issue is still there. However the issue is not relevant today, so maybe we can re-assess the position when the issue becomes real?

[wking]

On Thu, Jun 22, 2017 at 12:48:38AM -0700, mattspencer-arm wrote: … I wouldn't say its obsolete, because the issue is still there.

But with #850 and opencontainers/image-spec#699 any remaining arch-labeling concerns are image-spec issues and no longer runtime-spec issues.