>
> Here's a more definitive version of the adaptation of your 2.1.*
> /proc/config.gz to 2.0.*.
>
Just one word here.
5 months ago we have reduced the kernel size rewriting /proc/pci, moving
to lspci all the ascii descriptions for pci devices, saving us to
make a kernel-space ascii description structure (thank you Martin).
Now someone came out and tell us: hey ... why not include the .config
informations into the kernel ? We can do this way: make a structure and
link it into the kernel.
Don't you feel a bit uneasy with this ? After all, someone cut here just
to see that some other one bloats there !
I don't want to start a thread about "don't bloat the kernel", okay ?
This is just a comment: I am conscious that we should have a way to
associate the System.map and may be the .config with their image, but the
answer must NOT be kernel bloat !
To support my idea with some code, I must say something about my
last week (part-time) kernel coding.
I have written something to associate the System.map to its kernel, and
note that I have not said "link it into the kernel" !
The code is still in development ... now I'm writing the locking code to
protect some kernel data from multiple process load/access/unload
(shared data that can be flushed when not needed) and I think I will post
a patch in the next few days, may be this evening ... who knows.
The principle of this thing is really simple:
1) make zImage (make bzImage)
2) cat System.map >> zImage (bzImage)
3) boot the new image
4) cat /proc/ksyms_internal will open the zImage (bzImage) file, read the
data at the end of image and show it.
The pros are:
- Data is NOT linked into the kernel (~ 130 Kb of data), so NO kernel
bloat, except of course for the /proc code.
- Data is associated with the kernel at link time so there is no way to
make mistakes: the System.map is associated with its kernel image
- /proc support to read the symbols from the kernel image and show them
catting /proc/ksyms_internal
- Data is loaded into the kernel memory only on-demand. If you
'cat /proc/ksyms_internal' the data is loaded, showed and flushed
- The code now support the System.map file, but no one prevent us to
include .config and other informations we want to associate with a
particular kernel image
- The kernel image 'seems' big, but the loaded kernel is not really bigger
than before, except for the /proc/ksyms_internal code
The cons are:
- The running kernel must know the position of boot image: I've done this
with an environment variable settable from the boot loader. For example
now I have booted the vmlinux.old:
boot_image_path=/boot/vmlinux.old
Now the running kernel knows the position System.map data is saved
to, so we know where to load the System.map data from
- If the kernel don't know boot_image_path, no data is showed. We must
rely on the administrator to set it up into the boot loader
- I don't know how to handle network boot, I don't boot this way so I have
no way to know how to make it right
- Now the code works only with i386 (but I feel there would not be
particularly difficult to implement the code for other archs too)
- There is (still) not a double check against kernel version, but I am
thinking on it (it is really important that the running kernel matches
the boot_image_path)
What about this ?
Patch coming soon if someone is interested.
Alan, Martin, David, Linus, Bill, all others ... is this just another
piece of ... err ... ehm ... shit ?
If you do not want to answer this question on the linux-kernel, please, at
least answer privately to my mailbox: I need your opinion to know if this
idea is good or bad and to know if /bin/rm -rf the code I have alredy
written or go on, finishing it and porting to other architectures.
PS: if someone want to see the code just right now, I can send it
privately. Note that I will send it only for review because it is not
ready for production.
Ciao,
Riccardo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu