Next up on creating armv7 MACHINE_ARCH: pre FCP stage

[Mark Millard]

On 2017-Jun-14, at 10:22 PM, Warner Losh <imp at bsdimp.com> wrote:

> On Thu, Jun 8, 2017 at 2:27 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
>> While the kernel doesn't really need an armv7 support, there will be a
>> better match to other systems if we create a armv7 MACHINE_ARCH. This will
>> be in addition to the armv6 MACHINE_ARCH we have today. This will allow us
>> to create a package set optimized for armv7 as well as armv6. While it is
>> true the RPI 1 is the only system that needs armv6 binaries, it's quite
>> popular and the Raspberry Pi folks keep creating new variants with the same
>> chip. It would also let us get the package stuff spun up and working before
>> we mess with armv6.
>> 
>> This would also separate the fate of armv6 and armv7 support at a later
>> time, but the weak consensus I've heard appears to be that the time isn't
>> yet right to discuss retiring armv6 support...
>> 
> 
> I've created a new FCP for this. You can comment on it at
> https://github.com/freebsd/fcp/pull/6 but the FCP number may change since
> the allocation isn't official. I've created this on the belief that
> everybody here is either agnostic or fully supports this path. The FCP
> tries to enumerate the work and impact, but currently needs your help to
> flesh things out. I've done a first pass, but it's lame still.
> 
> This is one of the first FCPs, so I'm going to use it a little as test case
> for the larger thing.  There will be bumps. Feels may get bruised, but if
> so accept my apologies and help me do better in the future.
> 
> I cc'd the re@ as a heads up that this may be coming down the pike and that
> discussions so far have been super hand-wavey on the RE@ side of things.
> I'd like to know what the actual impact will be so we can document it. At
> this stage, it's still in the draft stage and nothing is certain. This is
> my call for feedback, but call it 'pre-feedback' if I read FCP-0 wrong and
> am doing it wrong :) My gut tells me that to make my doc better, do it on
> the pull request. To raise serious issues that need to be discussed, reply
> to this message.
> 
> To talk about the many flavors of Rpi, about unified releases, 32-bit ports
> to A-53, or any other odd tangents, please do that in arm@, but I'd humbly
> request a new subject.
> 
> Comments?

I booted Ubuntu Mate on a BPI-M3 and tried:

$ uname -p
armv7l

$ uname -ap
Linux bpi-iot-ros-ai 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 UTC 2016 armv7l armv7l armv7l GNU/Linux

I was actually thinking that a "hf" might
show up in how they name things if it was
a hard float based build. But looking I
see in /lib/ :

. . .
drwxr-xr-x  3 root root  16384 Nov  4  2016 arm-linux-gnueabihf
. . .
lrwxrwxrwx  1 root root     30 Oct 14  2016 ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.23.so
lrwxrwxrwx  1 root root     24 Apr 21  2016 ld-linux.so.3 -> /lib/ld-linux-armhf.so.3
. . .

and in /lib/arm-linux-gnueabihf/ :

lrwxrwxrwx 1 root root 10 Oct 14  2016 /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 -> ld-2.23.so

so it appears armv7l was used for naming a
hard float build in uname -p.

Of course this does not check how uniform the
various linux distributions are about such
naming.

Still it may mean that for linux-matching "armv7"
might not be the right name for uname -p output.



===
Mark Millard
markmi at dsl-only.net