Reducing the size of kexec util

Lombard, David N dnlombar at ichips.intel.com
Wed May 7 14:38:54 EDT 2008


On Wed, May 07, 2008 at 02:14:14PM -0400, Neil Horman wrote:
> On Wed, May 07, 2008 at 10:58:29AM -0700, Lombard, David N wrote:
> > On Wed, May 07, 2008 at 01:28:36PM -0400, Neil Horman wrote:
> > > On Wed, May 07, 2008 at 10:11:30AM -0700, Lombard, David N wrote:
> > > > The current (20080324) kexec binary on x86 is 135KiB.  While not a
> > > > problem on a normal distro or runtime environment, it's a chubster
> > > > in an embedded role.
> > > > 
> > > > Has any thought been given to reducing its 'on-disk' footprint?
> > > > The rather obvious, non-default build-time options to only support
> > > > specific kernel types and capabilities, jumps to mind.
> > > > 
> > > > Beyond build-time options, a Busybox applet would further minimize
> > > > size, but maintenance would be painful...
> > > > 
> > > Busybox is precisely what I use to implement kdump in RHEL at the moment.  Its
> > > still a bit bloated, since it is meant for enterprise servers, but it makes it
> > > very easy to customize very small initramfs files for specific purposes.
> > 
> > Hmmm... Don't see a kexec or kdump in busybox-1.10.1.  Is this in git?
> > 
> > What did you do to reduce binary size?  I don't really care about process
> > size, as I'm not working with memory-constrained systems.
> > 
...
> If your goal is to simply reduce the size of the kexec binary, I think an old
> fashioned audit is in order.  Theres plenty of space to be saved too, I think.
> In particular there are lots of error checks that are re-created that could be
> made common.

Agreed...

-- 
David N. Lombard, Intel, Irvine, CA
I do not speak for Intel Corporation; all comments are strictly my own.



More information about the kexec mailing list