I posted a while ago WRT cutting down a stock 2.0.3x linux kernel.
I received a lot of excellent advice and recommendations. I also received
messages from several folks requesting a recap of the information I got
back. Well, here is most of it. I saved the emails I received and put
them all together below. Also, the number one place to start if you're
looking to make a custom, slim kernel, is the following URL:
http://rsphy1.anu.edu.au/~gpg109/mem.html
A lot of great advice came from here. It's mostly tailored to 1.x
kernels, but it's a wonderful place to start. Thanks to everyone who
responded, for providing this information.
cheers,
-bp
-- B. James Phillippe <bryan@Terran.ORG> UNIX, Linux, networks, C, Perl, Java, etc.------Included Mails, some sections omitted------- To: "B. James Phillippe" <bryan@Terran.ORG> Subject: Re: Shrinking kernel Date: Tue, 04 Nov 1997 18:25:40 -0300 From: Horst von Brand <vonbrand@inf.utfsm.cl>
"B. James Phillippe" <bryan@Terran.ORG> said: > This is a good point, but I think we're there already. The system boots > our own init and there is not much userland (no shells, no login, no > interactivity at all). In fact, there's no keyboard or monitor. The main > size constraint isn't as much memory as it is floppy-disk space. I'm more > concerned with the physical size of the zImage than it's memory footprint.
Use ROMFS on the diskette (and on the RAMdisk), it shaves some off the kernel and files use less space on disk.
Good luck!
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 --------------------------------------------------------------------- Date: Tue, 4 Nov 1997 17:53:19 -0500 From: Mark Hahn <hahn@neurocog.lrdc.pitt.edu> To: bryan@Terran.ORG Subject: re: shrinking kernelfind /usr/src/linux -name \*.o | xargs size | sort +2n | less
works fairly well. +2n sorts on bss; here are some relevant ones from my non-diskless 2.0.31, ignoring <4k. this is a bit of an overboard response, but I'm curious, myself... I think I've removed all the .o's that are actually library-like aglomerations.
some mild surprises: - bss: dcache and nfs/dir seem to be pretty big. - data: floppy presumably has a track buffer; sched has a bunch of rather important kernel arrays. - text: some of those drivers (tulip/serial/console/ide/floppy) seem pretty large.
and of course, none of this counts dynamic allocations.
bss over 4k:
3291 343 4100 7734 1e36 ./fs/inode.o 3501 2575 7168 13244 33bc ./drivers/block/ll_rw_blk.o 1713 199 8200 10112 2780 ./drivers/char/pty.o 1039 25 9216 10280 2828 ./kernel/printk.o 922 0 13576 14498 38a2 ./fs/dcache.o 4976 885 23560 29421 72ed ./fs/nfs/dir.o
data over 4k:
0 4784 0 4784 12b0 /usr/src/linux/drivers/char/defkeymap.o 29680 5086 108 34874 883a /usr/src/linux/arch/i386/kernel/kernel.o 12802 5290 0 18092 46ac /usr/src/linux/drivers/net/tulip.o 15820 9755 1104 26679 6837 /usr/src/linux/drivers/char/serial.o 6397 9934 0 16331 3fcb /usr/src/linux/drivers/pci/pci.o 28828 10092 2928 41848 a378 /usr/src/linux/drivers/block/floppy.o 6598 16158 0 22756 58e4 /usr/src/linux/kernel/sched.o
text over 4k:
4158 500 2076 6734 1a4e /usr/src/linux/scripts/lxdialog/textbox.o 4244 809 48 5101 13ed /usr/src/linux/drivers/char/keyboard.o 4426 352 12 4790 12b6 /usr/src/linux/net/core/dev.o 4456 1186 0 5642 160a /usr/src/linux/fs/ext2/balloc.o 4476 310 0 4786 12b2 /usr/src/linux/fs/ext2/inode.o 4510 151 592 5253 1485 /usr/src/linux/ipc/msg.o 4717 408 129 5254 1486 /usr/src/linux/fs/locks.o 4750 2112 1024 7886 1ece /usr/src/linux/fs/ext2/super.o 4976 885 23560 29421 72ed /usr/src/linux/fs/nfs/dir.o 5010 1250 0 6260 1874 /usr/src/linux/kernel/sysctl.o 5167 66 512 5745 1671 /usr/src/linux/ipc/sem.o 5350 901 0 6251 186b /usr/src/linux/fs/isofs/inode.o 5364 721 512 6597 19c5 /usr/src/linux/ipc/shm.o 5410 380 0 5790 169e /usr/src/linux/fs/isofs/rock.o 5438 23 68 5529 1599 /usr/src/linux/kernel/sys.o 5531 584 0 6115 17e3 /usr/src/linux/net/ipv4/af_inet.o 5784 371 0 6155 180b /usr/src/linux/mm/mmap.o 5789 352 0 6141 17fd /usr/src/linux/net/ipv4/ip_output.o 5907 888 0 6795 1a8b /usr/src/linux/fs/super.o 5909 170 0 6079 17bf /usr/src/linux/mm/filemap.o 6036 1670 0 7706 1e1a /usr/src/linux/fs/proc/array.o 6166 420 0 6586 19ba /usr/src/linux/arch/i386/kernel/irq.o 6198 710 0 6908 1afc /usr/src/linux/mm/memory.o 6213 5 0 6218 184a /usr/src/linux/fs/namei.o 6397 9934 0 16331 3fcb /usr/src/linux/drivers/pci/pci.o 6598 16158 0 22756 58e4 /usr/src/linux/kernel/sched.o 6672 320 0 6992 1b50 /usr/src/linux/net/unix/af_unix.o 6985 303 152 7440 1d10 /usr/src/linux/net/ipv4/route.o 7093 231 64 7388 1cdc /usr/src/linux/net/socket.o 7284 24 0 7308 1c8c /usr/src/linux/drivers/char/vt.o 7326 417 0 7743 1e3f /usr/src/linux/net/ipv4/tcp_output.o 7806 513 0 8319 207f /usr/src/linux/fs/nfs/proc.o 8082 193 0 8275 2053 /usr/src/linux/drivers/char/n_tty.o 8322 222 0 8544 2160 /usr/src/linux/fs/binfmt_elf.o 8326 285 0 8611 21a3 /usr/src/linux/fs/ext2/namei.o 8669 532 20 9221 2405 /usr/src/linux/net/ipv4/arp.o 9444 1052 4 10500 2904 /usr/src/linux/fs/buffer.o 9472 275 0 9747 2613 /usr/src/linux/net/ipv4/tcp.o 9905 1316 376 11597 2d4d /usr/src/linux/drivers/char/tty_io.o 10360 1350 140 11850 2e4a /usr/src/linux/net/core/core.o 10448 511 0 10959 2acf /usr/src/linux/net/ipv4/tcp_input.o 10512 112 1348 11972 2ec4 /usr/src/linux/drivers/char/random.o 11413 1098 0 12511 30df /usr/src/linux/drivers/block/ide-cd.o 12802 5290 0 18092 46ac /usr/src/linux/drivers/net/tulip.o 14247 5924 0 20171 4ecb /usr/src/linux/fs/proc/proc.o 15820 9755 1104 26679 6837 /usr/src/linux/drivers/char/serial.o 15990 601 773 17364 43d4 /usr/src/linux/drivers/char/console.o 17667 2637 8 20312 4f58 /usr/src/linux/drivers/block/ide.o 28828 10092 2928 41848 a378 /usr/src/linux/drivers/block/floppy.o 34968 0 0 34968 8898 /usr/src/linux/arch/i386/kernel/head.o --------------------------------------------------------------------- Date: Wed, 5 Nov 1997 09:14:22 +0100 From: Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de> To: bryan@Terran.ORG Subject: Re: Shrinking kernel
> I'm faced with the task of reducing the size of a > minimally-configured linux-2.0 kernel.
Bryan, I think it would have been appropriate to send your .config to the list. Otherwise, people now guess what options you already came up with. Here are some suggestions: - filesystems: keep everythibg but one. Do you really need /proc? Also, there is a read-only file system called romfs. It is included in 2.1 only, but 2.0 versions are also available. It uses only 4K instead of the 64K that ext2 uses. - PCI: the kernel has a table of all known vendor and device names to display in /proc/pci. You probably don't need this. - loadable modules: the symbol table takes quite some memory. Disable loadable modules if you can.
Hope this helps, Martin ----------------------------------------------------------------------- Date: Wed, 5 Nov 1997 10:49:19 +0000 (GMT) From: Mark Hemment <markhe@nextd.demon.co.uk> To: "B. James Phillippe" <bryan@terran.org> Subject: Re: Shrinking kernel
On Tue, 4 Nov 1997, B. James Phillippe wrote: > This is a good point, but I think we're there already. The system boots > our own init and there is not much userland (no shells, no login, no > interactivity at all). In fact, there's no keyboard or monitor. The main > size constraint isn't as much memory as it is floppy-disk space. I'm more > concerned with the physical size of the zImage than it's memory footprint.
Ignore me if I'm stating the obvious; 1) Are you using "make bzImage"? 2) If you are not interested in meaningful kernel messages, there are a lot of strings you can hack on. 3) Are you using swap at all? There is no build option to get rid of it, but the necessary hacking under mm/ isn't too difficult (mail me if you need help here). 4) If you are only running on Pentium boxes, have you looked at using the pgcc to compile the kernel? (a Pentium compiler, it generally produces smaller code - sorry don't have a URL handy, but a search of AltaVista should through up some useful links - the pgcc site has several mirrors).
Regards,
markhe -------------------------------------------------------------------------- Date: Wed, 5 Nov 1997 17:10:56 -0500 (EST) From: Linux Developer <kernel@enigma.pagannet.org> To: "B. James Phillippe" <bryan@Terran.ORG> Subject: Re: Shrinking kernel
On Tue, 4 Nov 1997, B. James Phillippe wrote:
> Hello hackers,
Well hello there, James. :) > I'm faced with the task of reducing the size of a > minimally-configured linux-2.0 kernel. The kernel I'm using now is > running a diskless firewall (boots from floppy, runs in a ramdisk). The > only things built into it are the floppy driver, TCP/IP networking > (forwarding, gatewaying, IP firewalling, masq, et al), and the ethernet > drivers. It's pretty small as is, but I'd like to push the envelope, so > to speak. :) I recall a great while ago some people who had downsized the > kernel by amazing proportions. I'm hoping someone can offer me advice as > to what areas I can hand-prune to tighten it up a bit. My boss (and > fellow engineer) has suggested cutting into fd.c and pulling support for > everything but the standard 1.44MB 3.5" floppy we're using. Can anyone > give any other advice for how to minimize the zImage?
Best things to do; Strip that bloody fd.c as much as possible. :) Take a look at all your ethernet drivers. Snip the comments. Snip extraneous probing addresses. Hell, rip out all the comments from socket.c and that'll take it down by a k or two. :) Hope this helps! :)
-Phillip R. Jaenke [InterNIC Handle: PRJ5] (kernel@prj.pcimporters.com) MIS Department, PC Importers, Inc. 800.319.9284, x4262 Head of Development, The Improvement Linux Project.