Messages in this thread | | | Date | Tue, 22 May 2001 11:55:32 +0200 | From | "Martin.Knoblauch" <> | Subject | Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo |
| |
"Martin.Knoblauch" wrote: > > >> > >> Hi, > >> > >> while trying to enhance a small hardware inventory script, I found that > >> cpuinfo is missing the details of L1, L2 and L3 size, although they may > >> be available at boot time. One could of cource grep them from "dmesg" > >> output, but that may scroll away on long lived systems. > >> > > > >Any particular reason this needs to be done in the kernel, as opposed > >to having your script read /dev/cpu/*/cpuid? > > > > -hpa > > terse answer: probably the same reason as for most stuff in > /proc/cpuinfo :-) >
After some checking, I could have made the answer a bit less terse:
- it would require that the kernel is compiled with cpuid [module] support - not everybody may want enable this, just for getting one or two harmless numbers. - you would need a utility with root permission to analyze the cpuid info. The cahce info does not seem to be there in clear ascii. - this limits my script to root users, or you need the setuid-bit on the utility. Not really good for security. - the cpuid stuff is i386 specific [today]. So are my changes. But implementing them for other architectures [if there is interest in the info] would not require to also implement the cpuid on other architectures. Which may not make any sense at all.
So, having the numbers in clear text in the cpuinfo file looks simpler and safer to me, although reading /dev/cpu/*/cpuinfo maybe more versatile [on i386] - at some cost.
Question: are there any utilities or other uses for the cpuid device today? Just interested. The kernel seems to work well without it.
Cheers Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |