Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand the list of valid instruction set specifiers #69

Closed
petrosagg opened this issue Jul 12, 2015 · 4 comments
Closed

Expand the list of valid instruction set specifiers #69

petrosagg opened this issue Jul 12, 2015 · 4 comments

Comments

@petrosagg
Copy link

Currently the spec states that the arch property in config.json should conform with the Go language spec. However, this spec only covers the following architectures: amd64, 386 and arm.

Since one of the goals of the Open Container Project is to support multiple architectures, and given the fact that, at least for ARM [1], it is very common to have different versions and different extensions depending on the SoC, the current list is insufficient.

Common architectures include armv5, armv6 and armv7a. The list could be further expanded by adding armv5, mips and powerpc. Another dimention that should be put into consideration is whether or not the architecture features a floating point unit, which will require architecture specifiers such as armv7ahf, armv6hf, mipseletc.

A good source of conventions can be found in the source code of the Open Embedded project [2]. Doing a quick grep for available architecture specifiers (AVAILTUNES) yields the following list:

aarch64,aarch64_be,arm1136jfs,arm920t,arm926ejs,arm9tdmi,armv4,armv4b,armv4t,armv4tb,armv5,armv5b,armv5b-vfp,armv5e,armv5eb,armv5eb-vfp,armv5ehfb-vfp,armv5ehf-vfp,armv5e-vfp,armv5hfb-vfp,armv5hf-vfp,armv5t,armv5tb,armv5tb-vfp,armv5te,armv5teb,armv5teb-vfp,armv5tehfb-vfp,armv5tehf-vfp,armv5te-vfp,armv5thfb-vfp,armv5thf-vfp,armv5t-vfp,armv5-vfp,armv6,armv6b,armv6b-novfp,armv6hf,armv6hfb,armv6-novfp,armv6t,armv6tb,armv6tb-novfp,armv6thf,armv6thfb,armv6t-novfp,armv7a,armv7ab,armv7ab-neon,armv7ahf,armv7ahfb,armv7ahfb-neon,armv7ahf-neon,armv7ahf-neon-vfpv4,armv7a-neon,armv7at,armv7atb,armv7atb-neon,armv7athf,armv7athfb,armv7athfb-neon,armv7athf-neon,armv7athf-neon-vfpv4,armv7at-neon,c3,core2-32,core2-64,core2-64-x32,corei7-32,corei7-64,corei7-64-x32,cortexa15,cortexa15hf,cortexa15hf-neon,cortexa15-neon,cortexa15t,cortexa15thf,cortexa15thf-neon,cortexa15t-neon,cortexa5,cortexa5hf,cortexa5hf-neon,cortexa5-neon,cortexa5t,cortexa5thf,cortexa5thf-neon,cortexa5t-neon,cortexa7,cortexa7hf,cortexa7hf-neon,cortexa7hf-neon-vfpv4,cortexa7-neon,cortexa7t,cortexa7thf,cortexa7thf-neon,cortexa7thf-neon-vfpv4,cortexa7t-neon,cortexa8,cortexa8hf,cortexa8hf-neon,cortexa8-neon,cortexa8t,cortexa8thf,cortexa8thf-neon,cortexa8t-neon,cortexa9,cortexa9hf,cortexa9hf-neon,cortexa9-neon,cortexa9t,cortexa9thf,cortexa9thf-neon,cortexa9t-neon,cortexm1,cortexm3,cortexr4,ep9312,i586,i586-nlp-32,iwmmxt,mips,mips32,mips32el,mips32el-nf,mips32-nf,mips32r2,mips32r2el,mips64,mips64el,mips64el-n32,mips64el-nf,mips64el-nf-n32,mips64-n32,mips64-nf,mips64-nf-n32,mipsel,mipsel-nf,mips-nf,powerpc,powerpc64,powerpc-nf,ppc476,ppc603e,ppc64e5500,ppc64e6500,ppc64p5,ppc64p6,ppc64p7,ppc7400,ppce300c2,ppce300c3,ppce300c3-nf,ppce500,ppce500mc,ppce500v2,ppce5500,ppce6500,ppcp5,ppcp6,ppcp7,sh3,sh3eb,sh4,sh4a,sh4aeb,sh4eb,strongarm,x86,x86-64,x86-64-x32,xscale,xscale-be

The above list is not exhaustive of the variations that each platform can have but it should be a good start of available architectures.

Something to note is that the Open Embedded project uses x86-64 instead of amd64. Currently all built the images in the docker registry have their Arch field set to amd64 so it might be a sensible exception.

[1] https://en.wikipedia.org/wiki/List_of_instruction_sets#ARM
[2] https://github.com/openembedded/oe-core/tree/master/meta/conf/machine/include

@mrunalp
Copy link
Contributor

mrunalp commented Jul 14, 2015

Thanks! This looks quite exhaustive. @philips @crosbymichael WDYT about supporting this list? Maybe in draft-next?

@glevand
Copy link

glevand commented Jul 14, 2015

This same issue was raised in #39.

I think it is important that spec state exactly how the platform ABI is described in the config so there will be only a single way to do so and without ambiguity.

@philips
Copy link
Contributor

philips commented Jul 14, 2015

I am going to close this in favor of #39 and put my thoughts over there.

@petrosagg
Copy link
Author

Alright, I'll jump on that thread

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants