From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: Cleaning up elkscmd and adding help text - Questions Date: Fri, 27 Mar 2015 18:41:24 +0000 Message-ID: <20150327184124.560d1461@www.etchedpixels.co.uk> References: <551512AC.5050704@gmail.com> <551558D7.8040000@jodybruchon.com> <20150327141010.408a65ac@www.etchedpixels.co.uk> <89B9B0F1-40FF-41C5-A438-B9E32145B2D4@jodybruchon.com> <55159F4A.1000808@gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55159F4A.1000808@gmail.com> Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: MFLD Cc: ELKS > 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