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.html [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-scalable-vector-extension-sve-for-the-armv8-a-architecture _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
