As per the suggestion of the lkml FAQ section 7-7, I have spent some time
working on a script to automatically go through the Linux source tree and
generate a stripped down version of the kernel source code (x86 only), along
with a few additional 'modules' which will contain additional funtionality,
if desired (such as irda or scsi support).
I have requested an account on kernel.org, and hope to run/test this script
for each full, stable release. I would like all of the input possible on the
script. Please note that this is the first version, so there are probably
many rough areas.
For a copy of the script please try:
http://garrett.dyndns.biz/makemini.sh.bz2
Please Cc: all comments to:
Garrett Kajmowicz
[email protected]
Thank you for your suggestions.
Garrett Kajmowicz wrote:
> As per the suggestion of the lkml FAQ section 7-7, I have spent some time
> working on a script to automatically go through the Linux source tree and
> generate a stripped down version of the kernel source code (x86 only), along
> with a few additional 'modules' which will contain additional funtionality,
> if desired (such as irda or scsi support).
>
> I have requested an account on kernel.org, and hope to run/test this script
> for each full, stable release. I would like all of the input possible on the
> script. Please note that this is the first version, so there are probably
> many rough areas.
>
> For a copy of the script please try:
>
> http://garrett.dyndns.biz/makemini.sh.bz2
>
> Please Cc: all comments to:
>
> Garrett Kajmowicz
> [email protected]
1. There is a distinct dearth (hmm an anagram of redhat) of loops.
2. When trashing the source like this you may as well remove
trailing whitespace (reduces kernel by 200K after compression).
3. What's the difference in size between 2.4.19.tar.bz2 and
2.4.19-bastardized.tar.bz2 ?
4. Is this just for (a) removing redundant code after installation or
(b) providing subset version(s) for download.
5. If 4(a) wouldn't you need to parse the .config to find the appropriate
bits to remove?
P?draig.
> 2. When trashing the source like this you may as well remove
> trailing whitespace (reduces kernel by 200K after compression).
I do not modify the source code files themselves. I simply 'prune' the tree,
creating 'dummy' Config.in and Makefiles as requred to prevent things from
breaking too much. The only file that I edit in any way is the config.in in
arch/i386 to change the scsi enabled default from y to n. This was so that
people who don't download the scsi 'module' don't run into problems with
compile failing. I will be making a few patches to the source tree for the
Config.in files to make this and other relted things less likely to happen.
> 3. What's the difference in size between 2.4.19.tar.bz2 and
> 2.4.19-bastardized.tar.bz2 ?
Size of some of the packages that I have done with this script:
linux-2.4.19-base.tar.bz2 - 11 MB
linux-2.4.19-scsi.tar.bz2 - 2.5 MB
There are currently 15 other 'modules', not listed here
> 4. Is this just for (a) removing redundant code after installation or
> (b) providing subset version(s) for download.
This will provide a subset for download. Due to not having the ability to
host, it may be applied to the full code after download for testing purposes.
> 5. If 4(a) wouldn't you need to parse the .config to find the appropriate
> bits to remove?
I prune the tree at the directory level. If I do not want/need irda support,
I wipe out the irda directory, recreate it with a dummy Makefile and
Config.in file so the make menuconfig script doesn't break, and the kernel
will compile. This results in less savings, but in higher stability/
reliability.
On Tuesday 01 October 2002 13:52, Padraig Brady wrote:
> 3. What's the difference in size between 2.4.19.tar.bz2 and
> 2.4.19-bastardized.tar.bz2 ?
Surely you meant "bowdlerized"?
--
Daniel
On Tue, Oct 01, 2002 at 06:48:34PM +0200, Daniel Phillips wrote:
> On Tuesday 01 October 2002 13:52, Padraig Brady wrote:
> > 3. What's the difference in size between 2.4.19.tar.bz2 and
> > 2.4.19-bastardized.tar.bz2 ?
>
> Surely you meant "bowdlerized"?
nup, my understanding of that term is (in the cloak+dagger sense)
blacking out the sensitive bits with a big marker pen, typically before
showing them to people who shouldn't see the sensitive bits.
a quasi-sane way to do this bastardisation of the kernel sources would
be to do a make allyesconfig and remove anything that doesn't match up.
but given the amount of kernel source dedicated to generic drivers or
subsystems on any arch i think its a total waste of time, and i'm not
alone :-)
j.
--
toyota power: http://indigoid.net/
> a quasi-sane way to do this bastardisation of the kernel sources would
> be to do a make allyesconfig and remove anything that doesn't match up.
> but given the amount of kernel source dedicated to generic drivers or
> subsystems on any arch i think its a total waste of time, and i'm not
> alone :-)
I saw a way to help listed in the FAQ for this list. If people seriously
think that my time will be wasted, please let me know and I will not waste my
time.
- Garrett Kajmowicz