[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of the ARM ports BoF at DC16



On Thu, Aug 11, 2016 at 11:47:12AM +0000, Riku Voipio wrote:
>On Fri, Jul 22, 2016 at 02:36:05AM +0100, Steve McIntyre wrote:
>> armhf
>> =====
>> Current port, first released with Wheezy. Due to cross-distro effort,
>> this setup (ARMv7 EABI using VFPv3D-16) is the default supported
>> 32-bit ARM architecture in all distros now. We've got a couple of
>> kernel variants that will support just about any new devices shipping,
>> given updated drivers and device tree support.
>
>One issue with armhf is NEON support. Currently we support NEON as long
>upstreams provide a runtime mechanism to use it. There are however a
>couple of issues here
>
>- Some upstreams (chromium) do neon compile-time or require neon to
>  work at all (rustc)
>- The amount of non-NEON armv7 hw is very minimal (dove, tragra2, ?), so
>  majority of armhf users have less performance than they could
>- None of the armhf buildd's have NEON support, so no NEON code can be
>  run build-time (testuites etc)
>
>Once the next armhf buildd upgrade comes around (preferrably in form of
>armhf vm's running on arm64 servers), I think we should discuss make NEON a
>requirement for armhf.

I disagree strongly, for multiple reasons:

 * there are a non-negligible number of non-NEON ARMv7 machines in the
   wild
 * we spent a very long time agreeing across the distros on the spec
   for armhf, and I don't want to lose the cross-distro binary
   compatibility that we fought for
 * I don't think that moving the ABI is a valid thing to do for the
   sake of some upstreams doing the wrong/lazy thing.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Is there anybody out there?


Reply to: