>
> On Sun, May 31, 1998 at 05:34:27PM +0200, Riccardo Facchetti wrote:
> > 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 !
>
> Most of the discussions lately have been about reducing the memory overhead
> of the feature and allowing it to free the memory when it is finished. Both
> patches have consumed less than 1K of memory at their biggest. The PCI
> strings were much bigger than that, were they not?
Yes of course, but my point is "if possible, no memory consumption at
all".
> > 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.
> >
> > - Data is NOT linked into the kernel (~ 130 Kb of data), so NO kernel
> > bloat, except of course for the /proc code.
>
> Which is probably bigger than the entire /proc/config patch :-)
I'm not sure about this, but may be.
Anyway, try to build a /proc/ksyms_internal patch in which you put the
System.map. I was not concerned by .config, my work was focused in
System.map and that 130 Kb is only the "virtual" zimage growth. The real
kernel image is untouched except for the /proc/ksyms_internal code.
> > - /proc support to read the symbols from the kernel image and show them
> > catting /proc/ksyms_internal
>
> > - 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
>
> What about a boot floppy. One argument for /proc/config was that you might
> be booting a kernel you got off the network or something like that. With
> those kernels, it's often the case that you just cat or dd them onto a
> floppy and boot. I always keep one of those incase LILO gets corrupted. In
> that case, the kernel image is NOWHERE that the kernel can find it.
Okay you are right. This is the real problem. What to do when the kernel
image is not immediately available.
> > - 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
>
> Fair enough. This is basically the same situation that I just picked up
> before.
Yes, and resolving this problem will allow us to have the image-related
data linkable to the kernel, at cost (near to be) zero !
Ciao,
Riccardo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu