std_detect: Remove /proc/cpuinfo-based detection #1747
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Status: All blockers have been resolved.
Blocked on #1746, rust-lang/libc#4338, and stdarch PR that uses the fix in libc (#1778).Assuming #1746, rust-lang/libc#4338, and stdarch PR that uses the fix in libc (#1778) will be merged, the only targets that might use this implementation are:
Looking at only the builtin target, included there are:
These are all tier 3 targets, and only arm actually uses cpuinfo-based detection. x86_64 does not use auxv/cpuinfo, and mips does not implement cpuinfo-based detection (#355). And, arm's feature detection API is currently unstable.
Also even if we consider future possible targets, file-related libc APIs should not be available for
*-linux-none
, so cpuinfo-based detection is effectively only for*-linux-uclibc*
targets (except when writing syscalls in inline assembly). And the version of*-linux-uclibc*
targets wheregetauxval
is not available has been broken since 1.78 (and probably no one other than me was aware of it)...So I think it is okay to remove this implementation, which will effectively no longer be used once the above PRs are merged.
(The other parts of std_detect_file_io (
/proc/self/auxv
) will be similarly effectively unused, but they are used in the tests for the auxv-based detection, so I'm leaving it for now.)Another advantage of doing this is that Linux (getauxval/prctl(PR_GET_AUXV)), FreeBSD(elf_aux_info), and OpenBSD(elf_aux_info) all support auxv-based detection and HWCAP* values are the same (although there is the case that it exists on only one side), so we can merge code for them like this.
Closes #231
Closes #355