> > My patch that
> > builds .config into the kernel (I'll post it later today after I test it a
> > bit) stands a couple orders of magnitude less chance, though it has quite
> > a bit more diagnostic value.
>
> I think both are probably a good idea, on balance. The .config
> inclusion needn't use more than about 1200 bytes at the extreme (if
> compressed, judging by mine), and one could hardly argue that this patch
> would break stuff... For space-conscious folk we can always make it a
> config option ;-))
This patch can be done two ways (and I might post both). One is build the
file in as __init_data and make it accessible through a command line
option "config" which is also marked __init. Zero post-init overhead. Some
scripting wizardry with gunzip, nm and objdump lets you pull the file out
of a compressed kernel image as well (though it's ugly - I'll probably
leave it for later).
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, but
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.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/