lkml.org 
[lkml]   [1997]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: procfs problems
    On Tue, 15 Apr 1997, Miguel de Icaza wrote:
    > > > And then, if people want to parse any of the extra information, they
    > > > should know the architecture specific information on the CPU before
    > > > attempting to parse it.
    > > It should be standardized. Right now there's *no* standardization in the
    > > kernel, which makes parsing the information the biggest pain in the ass.
    > > Having to write 5 different parsers for the same information is *not* the
    > > way to go.
    > Well, first problem is: which applications would really care about the
    > information on /proc/cpuinfo? i doubt there are any applications that
    > require this information besides probably the cpu type.

    This should not be an excuse to be sloppy.

    > We could have a standard part /proc/cpuinfo part for those
    > applications that care about this and a architecture-specific part.

    User continues to scratch head and can't figure out why different
    architectures display the same type of information in completely different
    formats...

    > The standard part should have:
    >
    > global: the port name, architecture type, number of cpus on the
    > system, number of active cpus on the system.
    >
    > per cpu: the cpu type, the fpu type, mmu type, bogomips.
    >
    > The rest should be architecture dependant.

    And why pray tell does one huge /proc/cpuinfo entry make more sense than
    e.g /proc/cpu/0 /proc/cpu/1 /proc/cpu/2?

    The SCSI system does it this way for multiple adaptors, IMHO it's The
    Right Way. Stuffing all the multiple CPU info in a single entry is the
    M$-way.

    -Dan


    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:3.029 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site