image-spec
image-spec copied to clipboard
opencontainers
Track amd64 variants
Context: https://github.com/golang/go/issues/45453
I'm not sure how much we want to track go's compiler support for various platforms, but given that we already kind of do, I'm opening this issue to start a discussion because the go proposal is likely accept, and variant says:
When the variant of the CPU is not listed in the table, values are implementation-defined and SHOULD be submitted to this specification for standardization.
Nice catch - I think it makes sense to add the micro-architectures as variants, just a few new table entries there (though, to be pedantic, not so much because I want to track the go compiler but rather because it is an upstream agreement among the vendors).
I'm somewhat indifferent on the baseline vs. "v1" debate..
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex
I'm somewhat indifferent on the baseline vs. "v1" debate..
I tend to agree, but having everything be v<integer> is nicer aesthetically :P
FYI the above accepted proposal is slated to be included in the upcoming Go 1.18: https://tip.golang.org/doc/go1.18#amd64
I'm seeing it in 1.18:
$ docker run --rm golang:1.18.5 go env GOAMD64
v1
This is only an issue, but I'd be open to a PR. We just need to be sure that adding this doesn't break existing implementations.
It would be really nice to have labeling options for uarch ; use case: heterogeneous compute clusters, with mixed hardware ( zen2, zen3, haswell, skylake, etc ) Unfortunately, GOAMD64 not covering this instruction sets hell.
It appears that containerd now supports amd64 variants, so I figured I'd link that PR and bump discussion here since I don't know what the greater ecosystem support is at the moment.
https://github.com/golang/go/issues/61476#issuecomment-1791156741 is also very recent and related (but for riscv64)
Personally, I agree we should document this and that we should follow Go and containerd's lead (v1, v2, etc).
The RISC-V architecture variant names have a very bad mouthfeel :). Wrong issue for this discussion, but linux/riscv64/rva23u is probably what I would do rather than footgun myself by assuming I can make the variant a number prefixed with “v”. Or potentially linux/riscv64/a20s (in the 32-bit case, drop 64). Definitely not foo/v20 or foo/v23 though like it is with arm and x86_64.
Doh yes, sorry, those were two separate thoughts that I didn't actually separate well -- I meant I'm +1 on v1, v2, etc for amd64 and separately that riscv64 variants are a thing we should be looking at / thinking about too. :sweat_smile:
More: we should probably also document power8 etc for at least ppc64le (not sure if there are other POWER platforms worth documenting that for); maybe also microarchitecture levels for System Z/s390x?
https://github.com/golang/go/blob/e85968670e35fc24987944c56277d80d7884e9cc/src/cmd/dist/build.go#L145-L185 https://github.com/golang/go/blob/e85968670e35fc24987944c56277d80d7884e9cc/src/internal/buildcfg/cfg.go#L58-L175
The risk for s390x is that there isn't a GOS390 or GOS390X variable (yet?) so if we document something it might be conflicting.
We got almost that with https://github.com/golang/go/issues/60905, where GOARM64 is being added, but with explicit v8.0, v8.1, etc and no support for a bare v8 at this time (which I think is fine, since it's pretty unambiguous in our case that v8 is v8.0, but that also means implementations currently parsing variant on arm64 should get ready to support a minor version too).