[lkml]   [2001]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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]
- 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
utility. Not really good for security.
- the cpuid stuff is i386 specific [today]. So are my changes. But
them for other architectures [if there is interest in the info] would
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean