>From a pure technical point of view, it seems just like bloat. But from a
distribution, maintenance, etc point of view, it's a godsend. It's a config
option, just like devfs and initrd, so just don't use it if you don't want
to.
One suggestion, make the config option have 2 choices to include it, one
which sets the ELF attribute to load it, the other which just puts it in the
file but doesn't load it.
Also, does it make sense to strip the kernel, reformat the symbols into
System.map, then put them back into the image?
Regards,
Jeremy
----- Original Message -----
From: "Ville Herva" <[email protected]>
To: "Mikael Starvik" <[email protected]>; "'Randy.Dunlap'"
<[email protected]>; <[email protected]>;
<[email protected]>; <[email protected]>
Sent: Tuesday, February 25, 2003 7:03 AM
Subject: Re: zImage now holds vmlinux, System.map and config in sections.
(fwd)
> I do appreciate that you find no use for this feature. You instructions
will
> work fine if one always compiles the kernel using the same discipline and
> and stores them under /boot on the same computer.
>
> Not everybody are always that careful. I know I'm not. I've copied tens of
> kernels to floppy ("cp bzImage /dev/fd0" because it's so easy to do), and
> lost track which one is which. I've copied kernels to other computers, and
> lost track which is which. I've made mistakes copying kernels to /boot,
and
> lost track which is which.
>
> I have been using Peter Breuer's proconfig patch and I have found it
useful.
> Just cat /proc/config, and there you have the config for the running
kernel
> - no matter if it was booted from a throw-away floppy, network or /boot.
> It only adds couple of kB to the bzImage, and I am ready to pay that
price.
>
> If you are not - well it is a config option for that very reason.
Jeremy Jackson wrote:
> From a pure technical point of view, it seems just like bloat. But from a
> distribution, maintenance, etc point of view, it's a godsend. It's a config
> option, just like devfs and initrd, so just don't use it if you don't want
> to.
It was precisely for those reasons I made the changes (Todd Inglett was nice
enough to push the changes for me, hence his name on the change set). The PPC64
arch is a server platform, so the extra disk space caused by the bloat in the
zImage isn't a problem. However, the benefits of having the attached sections
is a godsend when a customer calls you up with a kernel problem and all they
can give you (they may not be very adept with Linux) is the zImage and some
type of error message.
Russell King wrote:
> So you want to transfer the complete zImage, including the redundant
> configuration and system.map to the target over the network, only to
> have it thrown away?
For our architecture, why not? We're not short on disk space and we can
netboot, so no problems there. Yeah, for ARM and other embedded arches,
it may not be what you want to do, but for PPC64, it's a good solution.
Peter