Hi all,

I've now posted a couple of RFC kernel patch series ([2], [1]) proposing the bulk of the Linux user/kernel ABI for the Scalable Vector Extension (SVE) on AArch64.

There's an overview of the SVE architecture in [3] (no public specs yet, though).

Since there are some impacts on ABI backwards compatiblity, particularly due to enlargement of the signal frame (see [1] for more detail), I wanted to open the discussion up to a wider group of distro-oriented people.

The big unknown from my perspective is how much real-world software will actually break if the signal frame grows, and what sort of migration paths are feasible. For now, I adopt the policy of making things safe by default and providing a means for the distro maintainer to override it -- but this may also slow adoption unnecessarily, if hardly any software would break anyway.

People's experience and views on this kind of issue would be much appreciated.

Cheers ---Dave

[1] [RFC PATCH 00/10] arm64/sve: Add userspace vector length control API lists.infradead.org/pipermail/linux-arm-kernel/2017-January/478941.html

[2] [RFC PATCH 00/29] arm64: Scalable Vector Extension core support http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470507.h...

[3] Technology Update: The Scalable Vector Extension (SVE) for the ARMv8-A architecture https://www.community.arm.com/processors/b/blog/posts/technology-update-the-...