lkml.org 
[lkml]   [2000]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: What /proc should contain [was: /proc/driver/microcode]

    Peter T. Breuer writes:
    > "A month of sundays ago Ricky Beam wrote:"

    >> There shouldn't be one damned bit of english text in there anywhere.
    >
    > I disagree. procfs is the most important and useful reporting system
    > the kernel has.

    I hope you actually wrote serious proc-using code. If not, you should
    not argue. I wrote the new ps, and I think /proc is a crawling horror.

    My fix would be to add the exact same binary files that Solaris has
    and to make all non-process information invisible. The filesystem
    code could also be used for /sys or /kern, with a mount option to
    show everything but the processes.

    >>> languages often used to construct GUI and system monitoring
    >>> tools can easily handle text and files, and those programs
    >>> don't need to run as root.
    >>
    >> What? "system monitoring tools"? You're perl scripts can do practically
    >> everything a C program can do including processing binary data structures
    >> and making system calls (ioctls, etc.) -- don't tell me otherwise because
    >> I've done it many times before.
    >
    > But this is wrong ("evil"). They should't. Parsing is easy. Let them
    > parse. Binary structures are for C.

    Parsing kernel data is evil. The native format is binary. Parsing is
    something you do for human-supplied data.

    I'd love to have the binary structures for C. In spite of being
    100% C, "top" can use 50% of my CPU time. Real code is C anyway.

    >>> out of clusters, I can't see why you're attempting to gain minor
    >>> efficiencies at the API when the cost is making it harder to
    >>> do system monitoring.
    >>
    >> The data should be structured efficiently for those things that will be
    >> accessing it. Human readable text is the worst possible input to any
    >> computer program. Structuring data such that a human can read it directly

    Damn right. BTW, some people feel a need to tweak the format!!!
    Parsing assumptions get blown away when somebody does something
    weird to the data, like adding whitespace where there was none
    or changing the spelling of keywords in /proc/*/status.

    > Unfortuately for your argument, humans are the ones processing the
    > information, ultimately.

    Nope, most /proc access is does via programs written in C.
    Humans are not happy with one kernel-supplied output format.

    >> Programs are forced to parse english text to do anything. (kernel
    >
    > And that's dead easy. What's your beef?

    ROTFL!!!

    The /proc/*/status keyword SigCat was changed to SigCgt.
    This is fine for a human, but programs shouldn't have to deal
    with this. Plain text in /proc costs you both reliability and
    performance.

    >> sprintf()'s, program then sscanf()'s, processes, and printf()'s again.)
    >
    > So what? Who cares. It's supposed to be convenient. If that's what it
    > takes to be convenient, that's what it takes.

    NO. The kernel API is not supposed to be "convenient" for humans.
    The kernel API should not even be POSIX. The kernel API should be
    as fast as possible. It should efficiently support POSIX, Java,
    and even Win32. The C library should hide the kernel API, and there
    should be tools that humans can use.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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