GSOC 2013 project " Kernel Size Reduction for Embedded System "

[Adrian Chadd]

Well, it's relatively easy to experience what it's like.

Reboot your machine with 32mb. Try to do things like bring up network
interfaces. Snark when stupid stuff occurs, like you can't allocate
enough mbufs for the driver RX path _and_ run the ifconfig command to
completion to bring said interface up.

There's just a lot of code. You can start by cross-building one of the
MIPS kernels targeting a small system (eg AP121) and look at the
text/data sections of the resulting .o's. Group them together into
subsystems and take a look.

Now, as for what we can get away with - I'm still going through
another round of review. Yes, there's likely a bunch of syscalls or
syscall behaviours that we just don't need in the embedded world.
Things like all the POSIX compatible fine grained locking? Likely
don't need. But there's some reasonably big areas of bloat that we
could easy hit right now. I've chopped out some of the more silly
abuses in the past (posix acl code that only gets used by ZFS, always
being compiled in? Sigh.)

Eg:

   text    data     bss     dec     hex filename
  59772     160   49184  109116   1aa3c kern_umtx.o

That's a lot of both code and bss just for mutex handling, don't you
think? Do we really need 59KiB of code and 48KiB of BSS just for mutex
handling?

   text    data     bss     dec     hex filename
    184       0   12160   12344    3038 sc_machdep.o

.. 8 consoles? 12k of BSS? again, not much, but ..

adrian at lucy:~/work/freebsd/svn/src/sys/cam]> cat
/tmp/AP121-nodebug.txt | egrep 'ata'
   text    data     bss     dec     hex filename
  11536       0       0   11536    2d10 ata_all.o
  17624    1504      16   19144    4ac8 ata_da.o
   6388     448      16    6852    1ac4 ata_pmp.o
  18960     304       0   19264    4b40 ata_xpt.o

.. 52 odd KiB tied up in CAM ATA transport, which we don't use unless
the ATA code is compiled in. It's just sitting there, waiting for an
ATA device to come along.

lucy# cat /tmp/AP121-nodebug.txt | grep "vfs_" | grep -v devfs | sort -k3
   4160      48       0    4208    1070 vfs_acl.o
   4752      48       0    4800    12c0 vfs_export.o
   5464       0       0    5464    1558 vfs_extattr.o
   8128     288       0    8416    20e0 vfs_default.o
  11020     160       0   11180    2bac vfs_cluster.o
   7916      96      16    8028    1f5c vfs_lookup.o
  19908     144      16   20068    4e64 vfs_vnops.o
  34504     208      16   34728    87a8 vfs_syscalls.o
   3068      64      32    3164     c5c vfs_hash.o
  22700     208      32   22940    599c vfs_mount.o
   1760     144     160    2064     810 vfs_init.o
  14520      16     160   14696    3968 vfs_mountroot.o
  13996    1568     176   15740    3d7c vfs_cache.o
  64852    1680     256   66788   104e4 vfs_subr.o
  52188    2000     304   54492    d4dc vfs_bio.o

.. 260KiB just for VFS handling.

etc, etc.

I'd love to fix this, but I have to make a choice right now between
porting to more of the Atheros wifi/soc platforms, or tackling this
particular issue. I'd love for others to help out here. I'm sure that
reducing code size in general is going be beneficial on the lower end
platforms, even just in cache savings.

Thanks,


Adrian