[lkml]   [2001]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Yet another design for /proc. Or actually /kernel.
    On Wed, Nov 07, 2001 at 05:26:32PM -0800, H. Peter Anvin wrote:
    > > About the complexity. It only "looks" complex. But from the
    > > machine point of view it's very simple to parse.
    > > Note that the strong advantage of this isn't the quoting,
    > > you can quote anyway in 1000 different ways. The advantage
    > > is that data is structured and parsing does not rely on
    > > spaces or newlines, but just on ().
    > > With this syntax you can express data as complex and structured
    > > as you want but the parsing is still simple.
    > >
    > You just changed spaces and newlines to ( and ) -- it doesn't really solve
    > anything unless you want three levels of nesting or more; in which case
    > you have *WAY* too much data in a single proc item.
    > -hpa

    There are anyway different ways to output the same data, and yes,
    probably spaces/tabs/newlines are more human readable, but I think
    the right solution isn't something that limits a-priori the
    complexity of the output. This will make developers more prone
    to invent their own formats for special stuff. the lisp-like way
    allows you to automagically put a description of the format with
    little efforts, simple parsing, unlimited complexity.
    Maybe you want limited complexity, but the format isn't your limit

    About the two level of nesting, take a look at /proc/net/netstat.
    it's not very clear, but in lisp-like it can be translated to:


    and so on. For every kind of proc output you can find today, there
    is a good way to convert it in that format, that is at the same
    time used by all the entries. I think you will hardly get the same
    with space/tabs/newlines without to indirectly use it like (), that
    will probably result in something of more complex to generate/parse.

    I can't see any strong reason to adopt a format that will for sure
    fail at some time in the future.

    BTW I see that the idea isn't well accepted, so I'll be quiet ;)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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