> $ cat /system/cpufs/cpus/0/vendor_string > $ cat /system/cpufs/cpus/0/l2_cache_size > > be sufficient? If the information is available through the CPUfs interface it > is easy to build wrapper library in any language for accessing it > programmatically.
I like the objective of obtaining all the cpuid information in a human-interpretable and consistent way from both the kernel and userland. However, I am not convinced that the best solution is a file system like abstraction. The bottom line is that, most, if not all, CPU related information is already available in cpuid_info. Currently in the kernel, the information is available via various cpuid_get_* functions. I find that interface quite acceptable (even though it could use some extension). What we lack is the ability to extract the same information in userland. I think a much lighter weight solution is to provide a library to extract such information from cpuid_info. If we don't want to extend cpu_info for kstat, a new command "cpuinfo" can be introduced to present the properties. The file system abstraction adds quite a bit of complexity. I don't think it makes representing/interpreting the new complicate NUMA and CMT features any easier. For example, how do we show that L2 is shared between core 0 and core 1, and L3 is shared between core 0-3, without adding many more properties, and without visiting 4 directories? Thanks, Sherry
