> I like this idea a lot --- Stick the System.Map and .config as files
> into wherever the kernel gets installed with a unique number (perhaps
> a CRC), or a kernel byte filesize appended to the filename.
>
> eg. /boot/System.map.c3132b
> and /boot/.config.c3132b
>
> Then change procfs, to read the files from /boot, whenever a
> request is made for /proc/config.gz ...
>
> VOILA! Minimal kernel bloat, and exactly the functionality that
> we're looking for!
That's bloat without benefit. There are several possibilities:
1. user-space tools guess location and maybe get the right file (bad)
2. user-space tools guess, with a CRC to verify the guess (tolerable)
3. kernel loads file from /boot into /proc (useless bloat)
4. kernel contains the data (reliable solution)
Currently we use #1. Option #3 is just horrid, since it offers no
advantage over #2 while adding kernel bloat. (if you know where the
data is, then user-space can find it) Option #4 also increases kernel
code and data, but actually offers an improvement.
I'm using the posted patch (which does #3) as a way to prepare my
code for option #4. As a development tool, the patch is great.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu