lkml.org 
[lkml]   [1998]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
http://www.rtweb.net/theorb 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 majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans