Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: /proc/config patch update and a minor question (fwd) | Date | Tue, 14 Mar 2000 22:06:52 +0100 (MET) |
| |
"A month of sundays ago Michael Elizabeth Chastain wrote:" > Aha. I have to say: I would prefer a simpler, more robust design. > If you just take the .config file, compress that, and link it into > the system image, it's not very large. And then you are guaranteed > to get the same contents!
I know. This was the design rejected by the kernel gods, and the one I liked.
However, don't worry. One can compile the proc config patch as two modules, as I described, or as 1 kernel stump plus a module, or as one module, or as all-in kernel. In any compilation choice where the two halves are _together_ (all-in or 1 module), the keys are removed from the relational join at compile time.
And the keys themselves are sufficient and robust, being generated by the gnu cksum program. Robustness was my aim. That was why I didn't use assigned or nonstandard keys. But I think I could produce an extensible assigned table.
> Michael
BTW, I believe the original reason why ye gods rejected the config.gz design was because they couldn't guarrantee it stayed below 4k. That limit of proc readouts has been removed somewhere along the way, if one knows how. I had to do the trick to get the full unexpurgagated 12K printout.
bambam:/usr/oboe/ptb% cat /proc/config | wc 618 618 12906
(618 config options recorded, 12.9K chars). Incidentally, if I compress that, I get about 3.3K chars:
bambam:/usr/oboe/ptb% cat /proc/config | sed -e s/^CONFIG_// | gzip -c | wc 9 72 3294
That is about the same size as the kernel stump I use. I believe it measures at 618*4byte key + 618*1byte index + about 500-1K bytes overhead. And no compression.
So .. any idea why use_config() in mkdep.c wouldn't find all the CONFIG_* uses in the kernel source?
Peter
- 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/
| |