On Mon, Sep 05, 2011 at 11:10:10AM +0100, Peter Maydell wrote: > On 5 September 2011 10:52, Marcin Juszkiewicz > <marcin.juszkiew...@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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
