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-...