lkml.org 
[lkml]   [2004]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs
    From
    Date
    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@gurulabs.com>
    Senior Instructor
    Guru Labs, L.C. http://www.GuruLabs.com/
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:2.901 / U:0.464 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site