On 04/24/2012 03:06 PM, Ezequiel García wrote: > Hi, > > 2012/4/24 Gustavo Sverzut Barbieri <barbi...@profusion.mobi>: >>> It seems Linux is not aiming that low after all, however a little >>> effort to try to un-bloat the current >>> state of things can't hurt, right? >> >> Do you know the state of uCLinux, when those options are enabled it >> should be better, no? Or 1.5Mb is with such options? > > To avoid confusion: uclinux is basically a linux distribution; it is > made of a linux kernel and a filesystem. > The kernel included in latest uclinux distribution file is 3.x series, > and it is pretty much equally to a vanilla > kernel (as compiled from git). > > So, when compiling for m68k (coldfire) with just the bare minimum > options enabled: block layer, console drivers, > romfs, I got a 1.5 MB kernel. I was shocked by the bigness of the > number, but it doesn't seem to be easily > reduced.
Different processors have different machine code, some of which is more space-efficient than others. My Aboriginal Linux project cross compiles the same ~7 packages to a dozen different targets (with the goal of getting a native development environment you can run under qemu). I post binaries at http://landley.net/aboriginal/bin and here are the sizes of a few files from the root-filesystem tarballs under different architectures: 456432 root-filesystem-armv5l/bin/busybox 209600 root-filesystem-armv5l/bin/make 335484 root-filesystem-armv5l/lib/libuClibc-0.9.32.1.so 539015 root-filesystem-armv5l/usr/tools/bin/gcc 354308 root-filesystem-i586/bin/busybox 179216 root-filesystem-i586/bin/make 273640 root-filesystem-i586/lib/libuClibc-0.9.32.1.so 475934 root-filesystem-i586/usr/tools/bin/gcc 358996 root-filesystem-i686/bin/busybox 187952 root-filesystem-i686/bin/make 281832 root-filesystem-i686/lib/libuClibc-0.9.32.1.so 474169 root-filesystem-i686/usr/tools/bin/gcc 448708 root-filesystem-m68k/bin/busybox 220264 root-filesystem-m68k/bin/make 424756 root-filesystem-m68k/lib/libuClibc-0.9.32.1.so 489885 root-filesystem-m68k/usr/tools/bin/gcc 659504 root-filesystem-mips/bin/busybox 304204 root-filesystem-mips/bin/make 464632 root-filesystem-mips/lib/libuClibc-0.9.32.1.so 579962 root-filesystem-mips/usr/tools/bin/gcc 476852 root-filesystem-powerpc/bin/busybox 222124 root-filesystem-powerpc/bin/make 341680 root-filesystem-powerpc/lib/libuClibc-0.9.32.1.so 487931 root-filesystem-powerpc/usr/tools/bin/gcc 388252 root-filesystem-sh4/bin/busybox 202036 root-filesystem-sh4/bin/make 310628 root-filesystem-sh4/lib/libuClibc-0.9.32.1.so 210712 root-filesystem-sh4/usr/tools/bin/gcc 482168 root-filesystem-sparc/bin/busybox 228876 root-filesystem-sparc/bin/make 358432 root-filesystem-sparc/lib/libuClibc-0.9.32.1.so 524888 root-filesystem-sparc/usr/tools/bin/gcc 464544 root-filesystem-x86_64/bin/busybox 215808 root-filesystem-x86_64/bin/make 364992 root-filesystem-x86_64/lib/libuClibc-0.9.32.1.so 634843 root-filesystem-x86_64/usr/tools/bin/gcc Note how the sizes are all over the place for the same tools built in the same configuration by the same compiler version, just for different targets. I put both i586 and i686 in there to show how much variation you can get between minor architecture variants. Also, what format is that kernel in? If it's vmlinux, that's A) not compressed B) has some ELF overhead. > And we are not even talking about dynamic footprint, or filesystem > requirements! True. There's probably a lot that can get chopped out of there. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. _______________________________________________ Celinux-dev mailing list Celinux-dev@lists.celinuxforum.org https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
