lkml.org 
[lkml]   [1997]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: procfs problems
    On 16 Apr 1997, Stefan Monnier wrote:

    > Evan Jeffrey <ejeffrey@eliot82.wustl.edu> writes:
    > > > /proc -> /system/proc
    > > > /dev/fd -> /system/fd
    > > > /dev/scd0 -> /system/devices/scsi0/target6/lun0
    > > People are going to scream bloody murder about that. It breaks a lot of
    > > stuff. OTOH, whatever we do to /proc is going to break some stuff.
    [SNIPPED]
    Let me throw this idea at you.

    I think the /proc file system should be designed so that it
    can be readily read by machine-specific utilities. Further,
    its design should be predicated upon not breaking existing
    utilities when a new field in added or new functionality is
    provided. Old tools just don't display the new information.

    It is convenient that the /proc file-system is human readable,
    however its design should not be based upon a person's ability
    to read it, but rather upon the ability of a utility to
    rapidly parse the available information with a minimum of
    overhead.

    The format of a display should be left up to the developer of
    the utility that uses the /proc file-system information. There
    should be no attempt to make the contents of each of the /proc
    file-system files "pretty".

    Given this, I propose the following standardized format of a
    /proc file-system entry.


    1.00 A line is defined as an ASCII text string that ends in
    a line-feed.

    1.01 A line can be up to TBD bytes in length. This length
    shall be chosen so that an entire line may be read in one file
    read operation.

    2.00 The first line shall consist of the names of each of
    the subsequent fields.

    2.01 These names shall be delimited by a single space.

    2.02 Where names would normally have spaces, these spaces
    shall be replaced with the underscore character.

    2.03 The nature of the fields specified are such that the
    text, and the number of fields represented, can be readily
    extracted from the string first read from the file, using
    readily available 'C' runtime library functions.

    2.04 Every field depicted in the header, shall have a
    subsequent line of data in the file.

    2.05 If a file header contains a field that in not used in
    a specific platform, a blank line consisting of a single
    space, followed by the line-feed character, shall be used as a
    place-holder for that data.

    This space is important with some 'C' run-time libraries
    because a single line-feed without a preceding space is often
    misread.

    2.06 Any field that becomes unused or obsolete is renamed
    with the single character '?'. Fields may be reused at a later
    date if the utilities that use these fields are correctly
    written.

    2.07 Any utility reading the file header shall ignore any
    field consisting of a single '?'. It must also properly
    ignore, i.e., skip its subsequent data line.

    2.08 Any utility using /proc file-system data must not rely
    on a specific field offset. Instead, it must use the field
    name. This requirement, in fact, implements 2.07 as a side
    effect.

    2.09 Any utility using /proc file-system data shall
    properly handle any missing fields. This handling may range
    from quietly ignoring missing data, to exiting after a hard
    error message. In no case shall the utility crash, i.e., seg-
    fault if there are missing fields.

    Here is the existing entry for /proc/cpuinfo.

    processor : 0
    cpu : 586
    model : Pentium 75+
    vendor_id : GenuineIntel
    stepping : 12
    fdiv_bug : no
    hlt_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid : yes
    wp : yes
    flags : fpu vme de pse tsc msr mce cx8 apic
    bogomips : 66.36

    processor : 1
    cpu : 586
    model : Pentium 75+
    vendor_id : GenuineIntel
    stepping : 12
    fdiv_bug : no
    hlt_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid : yes
    wp : yes
    flags : fpu vme de pse tsc msr mce cx8 apic
    bogomips : 66.36

    My proposal would change this to:

    Ignore the fact that this editor will put in a line-feed after
    every line of text.

    processor cpu model vendor_id stepping fdiv_bug hlt_bug fpu
    fpu_exception cpuid wp flags bogomips processor cpu model
    vendor_id stepping fdiv_bug hlt_bug fpu fpu_exception cpuid wp
    flags bogomips
    1
    586
    Pentium 75+
    GenuineIntel
    12
    no
    no
    yes
    yes
    yes
    yes
    fpu vme de pse tsc msr mce cx8 apic
    66.36
    2
    586
    Pentium 75+
    GenuineIntel
    12
    no
    no
    yes
    yes
    yes
    yes
    fpu vme de pse tsc msr mce cx8 apic
    66.36

    Now, this isn't pretty. But it parses easily. Even if you do
    everything without sscanf() and friends, we readily have the
    following information after the first file read.

    o The number of data elements. (The number of characters
    with the value of 0x20 or below).

    o The names of the data elements and any to be ignored or
    skipped.


    Cheers,
    Dick Johnson
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Richard B. Johnson
    Project Engineer
    Analogic Corporation
    Voice : (508) 977-3000 ext. 3754
    Fax : (508) 532-6097
    Modem : (508) 977-6870
    Ftp : ftp@boneserver.analogic.com
    Email : rjohnson@analogic.com, johnson@analogic.com
    Penguin : Linux version 2.1.34 on an i586 machine (66.15 BogoMips).
    Warning : I read unsolicited mail for $350.00 per hour. Supply billing address.
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:0.026 / U:1.772 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site