lkml.org 
[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs
    On Aug 12 2004, at 00:13, Dave Jones was caught saying:
    > On Wed, Aug 11, 2004 at 03:41:17PM -0700, Deepak Saxena wrote:
    >
    > > - 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?
    >
    > For x86 at least, this can be entirely decoded in userspace using
    > the /dev/cpu/x/cpuid interface. See x86info for example of this.
    >
    > > - 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.
    >
    > ditto.

    OK, just saw that code now and my reponse is to remove that
    interface in the long-term and move cpuid into sysfs (and not
    export all the cache info separately). In theory we don't even
    need the xxx_bug fields as those can be determined from looking
    at CPU binary data.

    > As these require arch specific parsers anyway, I don't think it makes
    > too much sense making a kernel abstraction trying to make them all
    > look 'the same', and if it can be done in userspace, why bother ?

    If it is all done in userspace, then just having the raw binary
    data available via sysfs w/o kernel parsing is probably best. The
    question I have is are there any cross-platform userland tools/apps
    that just want to know things like cache-size w/o worrying about
    CPU specifics? Even if they do, I suppose they can be fixed to read
    that information from a binary blob and parse it dependent on
    the arch. ARM (other arch I really care about) could just output
    all the various ID registers into a binary blob and I am sure the
    same can be done for the other arches.

    > The only other concern I have is the further expansion of sysfs with
    > no particular gain over what we currently have. The sysfs variant
    > *will* use more unreclaimable RAM than the proc version.

    Agreed, but that hasn't kept other data such as PCI and partition
    information from moving into sysfs.

    > /proc/cpuinfo has done well enough for us for quite a number of years
    > now, what makes it so urgent to kill it now that sysfs is the
    > virtual-fs-de-jour ?

    Consitency in userspace interface. My understanding is that goal is to
    make /proc slowly return to it's original purpose (process-information)
    and move other data out into sysfs.

    ~Deepak


    --
    Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

    "Unlike me, many of you have accepted the situation of your imprisonment and
    will die here like rotten cabbages." - Number 6
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:05    [W:0.023 / U:0.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site