On Mon, Sep 05, 2011 at 11:10:10AM +0100, Peter Maydell wrote:
On 5 September 2011 10:52, Marcin Juszkiewicz marcin.juszkiewicz@linaro.org wrote:
W dniu 05.09.2011 11:28, Andrew Stubbs pisze:
Next question ... is /proc/cpuinfo really the best way to detect this?
I mean, is auxv a better approach? Or something else? What's the most efficient, and most stable API to read the CPU architecture, CPU model, and FPU/NEON availability?
There's some worry among the toolchain team that /proc/cpuinfo is a somewhat fragile and inefficient way to achieve this goal. Some insight from the kernel experts would be helpful!
Remember that there are cpus like imx51 to2 which have broken neon and this is shown in /proc/cpuinfo (no neon flag for them). So using own tests should also check what kernel has to say.
Yes, but that is indicated both in /proc/cpuinfo and in the auxv vector, so it doesn't make any difference to the "is parsing cpuinfo a good/bad idea" question.
Note that the hwcaps info in /proc/cpuinfo is generated from the same hwcaps word exposed via auxv so, for now, the information is identical.
I would normally rate parsing /proc/cpuinfo as being a bad idea, but /proc/cpuinfo is probably the only source of the part ID information, for now. This is a bit unfortunate, especially since the format of /proc/cpuinfo could change at some point in the future, but in practice it seems to have been pretty stable with respect to this particular piece of information.
---Dave