> Yes, it is still too large for a 1 MB address space, but don't you think > it would be worth giving a try to reduce the uclibc and Busybox > footprint, rather than doing the same job as the our friends ? Massively dieting a large C library (or indeed most large apps) is actually usually harder than just doing the job properly in the first place. There are trade-offs you make that differ when you've got 64K of space to play with and there are whole areas of implementation that you do differently. The same with kernels. One of the big problems ELKS has even after all this time is stuff like some of the waitqueue and disk logic inherited from Linux 1.x era. It's way way less compact than the implementation that would have been done from scratch because the Linux model was designed to scale to hundreds of processes and assumes that kernel data space is cheap. Neither is true. As a result of that design ELKS can't swap out the kernel stacks of idle processes either to other memory or to disk, which leaves it permanently starved of buffer space. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
