> The RATIONALE is that on a ppc with some flash, memory, network and
> nothing much else, I don't feel like parsing MS-DOS partitions,
> offering IPX networking etc., but that junk is still included in
> 2..current - unconditionally. And there is more...
Both dos partitions and IPX are already CONFIG_* options. As "conditional"
as you can get.
If you want to reduce memory bloat I would start with shrinking the
dynamic sized hashtables. That will likely give you several hundred KB
depending on the memory size, much more than you could get from
code size reductions.
Another obvious candidate for memory reduction would be mem_map
(struct page). If you accept some total memory size limit (256MB
with 4k pages) you could replace next_hash and pprev_hash with an
16bit index into mem_map and save 8 bytes per 4k of memory. Possible even
fold count into flags and save another 4 bytes per 4k of memory
For 256MB of memory this would be 768k. That's more than a stripped
down kernel has code in total.
Probably more could be saved by attacking other bloated data structures
in the kernel.
Really there are many targets that have bigger potential pay off
than just code shrinking.
If you want to shrink code:
The TCP/IP stack could be also put on a diet. You likely don't need
an backbone router class routing table manager in your embedded
system. The code is already modularized enough that it could be
replaced with a simple "client" implementation using linked
lists for routing tables with minor changes.
Unfortunately developing it is still quite some work.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/