Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Lamont R. Peterson]

On Wed, 2004-08-11 at 16:41, Deepak Saxena wrote:
> Following this email will be a set of patches that provide a first pass
> at exporting information currently in /proc/cpuinfo to sysfs for i386 and 
> ARM. There are applications that are dependent on /proc/cpuinfo atm, so we 
> can't just kill it, but we should agree on a kill date and require all
> arches & apps to transition by that point. I've added code to
> proc_misc.c to remind the user that the cpuinfo interface is going
> away (currently using arbitrary date ~1 year from now). I've also
> added a pointer to struct cpu that can be used by arch code to 
> store any information that might be needed during attribute printing.
> 
> Couple of questions:
> 
> - Do we want to standardize on a set of attributes that all CPUs
>   must provide to sysfs? bogomips, L1 cache size/type/sets/assoc (when
>   available), L2 cache (L3..L4), etc? This would make the output be the 
>   same across architectures for those features and would simply require
>   adding some fields to struct cpu to carry this data and some generic
>   ATTR entries to drivers/base/cpu.c.  I am all for standardized
>   interfaces so I'll do a first pass at this if desired.

I vote yes, but only to a point.  You are right; standardized interfaces
are a good thing.  For any architecture specific information, additional
fields should be available.  Perhaps either always following the
standardized sysfs entries or as an "extra-cpuinfo" (or
"[arch]-cpuinfo"?) sysfs node.

> - On an HT setup, do we want link(s) pointing to sibling(s)?

I like this idea, even if it is not necessary because siblings should be
listed sequentially together.  i.e. two physical CPUs with HT would be
cpu0, cpu1, cpu2 & cpu3.  Obviously, cpu0 & cpu1 go together and cpu2 &
cpu3 also go together.

> - Currently the bug and feature fields on x86 have "yes" and "no".
>   Do we want the same in sysfs or 1|0?

If the flags are not going to be decoded, then I say definitely 1|0.

> - Instead of dumping the "flags" field, should we just dump cpu
>   registers as hex strings and let the user decode (as the comment
>   for the x86_cap_flags implies.

I like this.  In fact, if it goes this way, then I will write a
"cpuinfo" program that will do all the decoding as a generic tool.

> I'll try to do MIPS, SH, and PPC when I get a chance (all I have access 
> to), but have other things to do for a while, so want comments on above 
> questions first. 

When you are ready, I can also get SPARC64 & AMD64 (Opteron 242).
-- 
Lamont R. Peterson <lamont@xxxxxxxxxxxx>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/

Attachment: signature.asc
Description: This is a digitally signed message part