Given the discussion about /proc, I'll announce a /proc/config patch
for 2.2.13 here, with 2.3.44 coming up. Get it from
ftp://oboe.it.uc3m.es/pub/Programs/proconfig-0.8.tgz
Alan .. PLEASE try and include this in one of your pre-releases. It
makes system admin easy, instead of difficult. Trying to find out
why a strange kernel image behaves the way it does (posssibly
good!) is not my favourite occupation.
You can compile this code nine ways:
1) zilch
2) two kernel modules, one tiny, one big (3-5K + 50K). The big one
is a load and immediate unload job.
3) kernel imprint of 3-5K plus the extra big temp module.
4) one kernel module, about 5-7K.
5) all in kernel, about 5-7K.
...
I've only modified the makefiles for i86, since I haven't tested it on
other arch's yet (and can only do sparc ..). It works correctly with
make menuconfig and friends.
This is a real honest binary data structures job. Not a gzip output
string. It prints out from /proc/config the way it needs to be to
be used as a .config directly.
bambam:/usr/oboe/ptb/lang/c/proconfig/proconfig-0.8% head /proc/config
CONFIG_3C515=m
CONFIG_6PACK=m
CONFIG_82C710_MOUSE=m
...
bambam:/usr/oboe/ptb/lang/c/proconfig/proconfig-0.8% cat /proc/config | wc
604 604 12601
You can hack it down about another 1KB, I guess. I put it up for grabs.
Peter
Here's bits from the readme that may be of interest here ...
A few details
-------------
The kernel imprint's what you see as the config.o module, when it's
NOT compiled into the kernel. On my setup, with about 400 kernel
options coded inside, it occupies 3890 bytes. I can shrink it more.
It contains three arrays: one set of 32bit digital signatures for
the names of the kernel compilation parameters, one set of 8bit
"tokens" for the parameter values, and the set of parameter values
themselves. These are typically the strings "y", "n", "m" and some
more. About 10 in all, average length 4 bytes.
It also contains some short routines for handling the /proc/config
display. Say 1KB of code. These require some temporary space in
order To "map" the printout efficiently. 2bytes per option.
On a 400 option setup, that's
4*400 + 1*400 + 10*4 + 1000 + 2*400 = 3920 bytes
What does that buy you? Well, it gets you a printout not of the
configuration parameter names, but the keys for them. You can
use an external utility to look them up if you're pressed. They're
computed with gnu "cksum" from the portion of the name after the
"CONFIG_". But it's not necessary. Loading and unloading the
config_data.o module will convert all the keys into the correct
names. The config_data.o module is big, but it's a temporary.
The keys do cost space. And 32 bit keys over 400 options
have approximately a 400^2/2 / 2^32 chance of collision. That's
about 1 / 2^16 chance of collision. 28 bit keys are also fairly
safe, but a bit of a hassle. 24 bit keys have about a half-percent
chance of collision. I might try it if people want to save space.
...
Compare the other approaches possible. The best I saw in the past
was the approach of blatting the .config file into a compressed
archive (sans CONFIG_ prefixes) and presenting it as
/proc/config.gz.
I've just done that with a sample distribution, and the result is:
ls -l /tmp/config.gz
-rw-r--r-- 1 ptb 2433 Feb 24 17:17 /tmp/config.gz
And that came from a 600 item config:
cat /proc/config | wc
604 604 12601
So gzip compresses those 12601 - 7*604 = 8400 bytes mighty handily!
It would result in about 3K of kernel code. But in the past people
have objected to this approach. I won't go into the reasons why.
(incidentally, leaving the CONFIG_ prefixes on, and then
compressing, leaves one with an extra 600 bytes in the compressed
code, one byte for each - repeated - prefix).
The upshot:
You get two bits of kernel code, and they can be compiled
in or out of the kernel as follows. Y means "compiled in kernel or
together with the other module". M means "compiled as module".
N means no.
module config.o config_data.o
config name PROC_CONFIG PROC_CONFIG_LUMP
------------------------------------------------
config value N N
bytes - -
------------------------------------------------
config value Y N
bytes 3-5K -
------------------------------------------------
config value Y M
bytes 3-5K 50K
------------------------------------------------
config value Y Y
bytes 2K 3-5K
------------------------------------------------
config value M N
bytes 3-5K -
------------------------------------------------
config value M N
bytes 3-5K -
------------------------------------------------
config value M M
bytes 3-5K 50K
------------------------------------------------
config value M Y
bytes 5-7K -
------------------------------------------------
Why is the data_config.o module so large? Well, without knowledge
of the kernel config itself, it has to contain key/name pairs for
all possible config options. Theer are 1404 of those in kernel
2.2.13. There are 1568 in kernel 2.3.44.
When it is compiled together with the config.o module, it occupies
a fifth of the space, firstly because it only need contain some of
the names, and secondly because it can dispense with the keys
entirely.
Beware, I haven't checked all these combinations. I expect to be
told if there's a problem with one of them.
To regenerate the data for the config_data.o module, run
make allconfigdata
in the kernel source tree. This runs a "find" over your source
for possible CONFIG_ names and puts the data in
kernel/all_config.data. I haven't put this into the kernel make
sequence, because it takes a while.
Requirements?
-------------
Gnu cksum. Gnu find. Gnu bash1. I avoided 2-isms.
I'd be grateful for C versions of the scripts in scripts/.
PTB 24/2/00
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:10 EST