lkml.org 
[lkml]   [2001]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PROPOSAL: dot-proc interface [was: /proc stuff]
    On Sun, Nov 04, 2001 at 05:59:45PM +0000, John Levon wrote:
    > On Sun, Nov 04, 2001 at 06:41:59PM +0100, Jakob Østergaard wrote:
    >
    > > The "fuzzy parsing" userland has to do today to get useful information
    > > out of many proc files today is not nice at all. It eats CPU, it's
    > > error-prone, and all in all it's just "wrong".
    >
    > This is because the files are human-readable, nothing to do with binary vs. plain
    > text. proc should be made (entirely ?) of value-per-file trees, and a back-compat
    > compatprocfs union mounted for the files people and programs are expecting.

    So you want generaiton and parsing of text strings whenever we pass an int from
    the kernel ?

    >
    > > However - having a human-readable /proc that you can use directly with
    > > cat, echo, your scripts, simple programs using read(), etc. is absolutely
    > > a *very* cool feature that I don't want to let go. It is just too damn
    > > practical.
    >
    > I don't see that it's at all useful: it just makes life harder. You yourself
    > state above that read(2) parsing of human readable files is "not nice at all",
    > and now you're saying it is "just too damn practical".

    cat /proc/mdstat - that's practical !
    cat /proc/cpuinfo - equally so

    Anyway - I won't involve myself in the argument whether we should keep
    the old /proc or not - I wanted to present my idea how we could overcome
    some fundamental problems in the existing framework, non-intrusively.

    >
    > Just drop the human-readable stuff from the new /proc, please.

    I don't care enough about it to discuss it now, but I'm sure others do ;)

    >
    > In what way is parsing /proc/meminfo in a script more practical than
    > cat /proc/meminfo/total ?

    I see your point.

    There's some system overhead when converting text/integer values, but
    if you're polling so often I guess you have other problems anyway...

    ...
    >
    > This just seems needless duplication, and fragile. Representing things as directory
    > hierarchies and single-value files in text seems to me to be much nicer, just as
    > convenient, and much nicer for fs/proc/ source...

    I like the idea of single-value files.

    But then how do we get the nice summary information we have today ?

    Hmm... How about:

    /proc/meminfo - as it was
    /proc/.meminfo/ - as you suggested

    That way we keep /proc looking like it was, while offering the very nice
    single-value file interface to apps that needs it.

    I could even live with text encoding of the values - I just hate not being able
    to tell if it's supposed to be i32/u32/i64/u64/float/double/... from looking
    at the variable. Type-less interfaces with implicitly typed values are
    *evil*.

    I'd love to have type information passed along with the value. Of course
    you could add a "f"_t file for each "f", and handle eventual discrepancies
    at run-time in your application.

    --
    ................................................................
    : jakob@unthought.net : And I see the elder races, :
    :.........................: putrid forms of man :
    : Jakob Østergaard : See him rise and claim the earth, :
    : OZ9ABN : his downfall is at hand. :
    :.........................:............{Konkhra}...............:
    -
    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 13:12    [W:4.519 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site