lkml.org 
[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Building .config into the kernel

On Thu, 14 Jan 1999, Oliver Xymoron wrote:

> However, I've seen a number of good arguments from MEC to go all the way
> and add /proc/config, which means adding ~5k of data into the kernel
> [...]

an order less than a ~5k .config, instead of bloat like this:

# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
CONFIG_M686=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y

it's enough to store:

EXPERIMENTAL
M686
X86_WP_WORKS_OK
X86_INVLPG
X86_BSWAP
X86_POPAD_OK
X86_TSC

my 7k .config can be stored in 600 bytes plaintext with this method, and i
have compressed it down the 300 bytes with gzip. Storing a stripped down
and gzip-ed .config in the kernel and reporting it to user-space via /proc
doesnt sound like a big overhead, and certainly simplifies/cleans up the
bug reporting process.

> also means always being able to recover config data and never having a
> confusion about which build is actually running. This, together with my
> patchnames patch, makes reporting kernel build information very easy to
> automate.

.config is a fact of life. I dont agree with your patches idea though,
'production quality patches' outside the main kernel are an artifact of
bad communication. we should _not_ make it easier. People playing with
'experimental patches' should be fully aware of the risks.

-- mingo


-
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:49    [W:0.201 / U:0.368 seconds]
©2003-2011 Jasper Spaans. Advertise on this site