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. st...@einval.com Is there anybody out there?
