On Fri, Oct 24, 2014 at 02:56:39PM +0100, Mark Rutland wrote:
Currently, the arm64 /proc/cpuinfo format differs from that of arm, in a manner which prevents some otherwise portable applications from functioning as expected. Specifically, the "Features" line describes the 64-bit hwcaps exclusive of the 32-bit hwcaps, which causes issues for certain applications which attempt to parse /proc/cpuinfo to detect features rather than directly using the hwcaps exposed via auxval.
Like it or not, but every file in procfs is a userspace API, and can be parsed by any program. If we change a procfs file and a userspace program then stops working, that's our fault, and our problem to fix (by restoring the information published there in a manner which userspace can parse.)
So, as you've found some programs which rely on this, ARM64 really does need to be compatible with ARM32 in this respect.
It's unfortunate that people have decided that parsing the ELF HWCAPs from /proc/cpuinfo is an acceptable way to go, rather than using the binary information passed, but procfs is a much more visible source of information than some binary interface which you need to read man pages to find.
That's the danger of publishing information in either procfs or sysfs. Once published, it becomes part of the userspace API, and it can become hard to remove it. This is why we should /always/ think very carefully about what we expose through these filesystems.