[lkml]   [1998]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [EXAMPLE-PATCH] /proc/config
    On Sat, 30 May 1998, Peter T. Breuer wrote:
    > "A month of sundays ago Martin Mares wrote:"
    > > I don't expect /proc/config to give _gzipped_ answer, so you either have
    > > to include ungzip code in the kernel or you cannot have the data compressed
    > > in memory. _Runtime_ size of the kernel is more important than the on-disk
    > > size.
    So? We already have gunzip code in the kernel _four_ _places_ (zImage, PPP,
    ftape, ramdisk). What we really need to do is write generic [de]compression
    service that all those clients can use. (We are currently using four
    different copies of the code, yes?)

    > Actually, that's not as silly as it sounds. Why CAN'T /proc/config.gz
    > give a gzipped answer? Presumably we're only reading it if we are
    > actually running a system, in which case gzip is available to
    > decompress it.
    Because /proc/config is largely an emergancy recovery tool. (OTOH, you need
    gzip to compile the kernel anyway (to untar it)).

    > The next simplest thing to do is code the config as a 2bit-map
    > (presumably of yes,no,module,don't know) according to some standard.
    > That requires decisions, and the registration of identification numbers
    > for config options, so it won't happen.
    No, the reason that it won't happen is that you can't encode strings or
    numbers that way, only tristates and bools.

    -=- James Mastros
    True mastery is knowing enough to bullshit the rest.
    -=- Me coming soon (or when I get around to it).

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.018 / U:13.080 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site