> 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/