W dniu 16.11.2022 o 10:26, Peter Griffin pisze:
What a great idea!
Thanks!
Interesting for me as I was just working on a bug where VFP stopped being reported to userspace for aarch32 mode in v6.1-rcs due to a rework in the kernel. That re-work happened in https://lore.kernel.org/all/20220909165938.3931307-2-james.mo...@arm.com and the fix for aarch32 being reported incorrectly went in here https://lore.kernel.org/linux-arm-kernel/20221103082232.19189-1-amit.kach...@arm.com/
But in short it may also be useful to capture the kernel version you tested in the table, as what is reported to userspace could change a bit especially with the latest v6.1 kernel.
Random ones as those entries are contributed by random people. Some were taken from online forums even.
I wonder also if capturing aarch32 features for each SoC is also worthwhile? You can use getauxval(AT_HWCAP2) api for that. See this link for more info https://community.arm.com/arm-community-blogs/b/operating-systems-blog/posts/runtime-detection-of-cpu-features-on-an-armv8-a-cpu
I base table only on /proc/cpuinfo dump. This way everyone has easy way to provide additional entries. Learnt that hard way with one of my previous projects.
If you require people to run some binary then even providing sources gets people suspicious.
_______________________________________________ linaro-dev mailing list -- linaro-dev@lists.linaro.org To unsubscribe send an email to linaro-dev-le...@lists.linaro.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
