Skip to content
This repository was archived by the owner on Aug 14, 2020. It is now read-only.

Conversation

@philips
Copy link
Contributor

@philips philips commented Apr 6, 2015

#284 as per comment by philips in rkt/rkt#730.

@philips
Copy link
Contributor Author

philips commented Apr 6, 2015

Deprecates #285

@jonboulle
Copy link
Contributor

historical discussion here: #6 (comment)

@philips
Copy link
Contributor Author

philips commented Apr 6, 2015

We are going to wait on this one until we can get more guidance on what types of ARM strings we should have here. It gets a little tricky because the ARM architecture has a number of types such as "armel", "armhf" and whatever arm64. We want to make sure we have a list and docs that understand these differences. If anyone knows of an authoritative list please let us know.

@yarwelp
Copy link

yarwelp commented Apr 6, 2015

@philips That is true. In the original issues I opened (#284 and rkt/rkt#730), you may note that I was talking about "armhf" and "armv7l". The former ("armhf") is the label Ubuntu and Debian at least are using in their packaging systems. The latter ("armv7l") is what is reported by uname -m on the same system -- this ties into the issue raised by @mpasternacki and linked to by @jonboulle above in that it is probably too specific a name to be useful.

Would you be willing to add just "armhf" initially? Or would that be a misnomer in the context of Go, you think?

I might also add that on my ARM computer, I have run the "armhf" Debian in a chroot on "armhf" Ubuntu, so at least to me, "armhf" seems to be a useful label to adopt.

Likewise, on an old Android phone I used to have, "armel" Debian was able to run in a chroot.

Furthermore, as sudo docker search armhf- will show you, at least some people are using the label "armhf" for their docker images and while this is not docker, it may be of use to note that.

@philips
Copy link
Contributor Author

philips commented Apr 6, 2015

@Erikano Yea, I want to be able to document our decision. I don't know where the canonical source is for these strings.

@cnelson
Copy link

cnelson commented Apr 6, 2015

Looks like they are just made up by the devs working on the port.

In practice armel will be used for older CPUs (armv4t, armv5, armv6), and armhf for newer CPUs (armv7+VFP).

See notes on arrmel vs arm and naming debate: https://wiki.debian.org/ArmHardFloatPort

cnelson

On Apr 6, 2015, at 16:14, Brandon Philips [email protected] wrote:

@Erikano Yea, I want to be able to document our decision. I don't know where the canonical source is for these strings.


Reply to this email directly or view it on GitHub.

@philips
Copy link
Contributor Author

philips commented Apr 10, 2015

We are trying to get a more authoritative answer offline with some folks involved in these projects, stay tuned.

@jonboulle
Copy link
Contributor

@philips I think we established that for now we can at least add aarch64,
right? That one seems to be clearly defined and standardised (even if not
yet widely implemented)

On Thu, Apr 9, 2015 at 6:11 PM, Brandon Philips [email protected]
wrote:

We are trying to get a more authoritative answer offline with some folks
involved in these projects, stay tuned.


Reply to this email directly or view it on GitHub
#287 (comment).

@philips
Copy link
Contributor Author

philips commented Apr 10, 2015

On Thu, Apr 9, 2015 at 6:34 PM, Jonathan Boulle [email protected]
wrote:

@philips I think we established that for now we can at least add aarch64,
right?

Yes, we can add aarch64. Maybe even aarch32?!

@jonboulle
Copy link
Contributor

deprecated (again) by #304

@jonboulle jonboulle closed this Apr 21, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants