From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 8 22:44:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 503EA561 for ; Mon, 8 Apr 2013 22:44:26 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 191B911B for ; Mon, 8 Apr 2013 22:44:26 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 9AE6335930C; Tue, 9 Apr 2013 00:44:23 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 6C8E62848C; Tue, 9 Apr 2013 00:44:23 +0200 (CEST) Date: Tue, 9 Apr 2013 00:44:23 +0200 From: Jilles Tjoelker To: Amit Rawat Subject: Re: GSOC 2013 project " Kernel Size Reduction for Embedded System " Message-ID: <20130408224423.GA64696@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 22:44:26 -0000 On Mon, Apr 08, 2013 at 08:28:04PM +0000, Amit Rawat wrote: > GSOC posted the list of selected organization for GSOC 2013 and I am > highly happy that FreeBSD is among the selected organization. > I am a third year student interested to work in the field of embedded > system. I applied last year and the title of my project was " Kernel > Size Reduction for Embedded System". The link to my last year proposal > is > https://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/amitrawat10/1#c8001 > But due to some flaws it doesn't get selected. I am looking to improve my > proposal for this year and apply again. I explain some portion of my > project pictorially on my blog > https://amit10rawat.wordpress.com/2013/02/26/kernel-size-reduction-for-embedded-system/ > I am looking for suggestion and new ideas by which I can reduce the > size of kernel. It looks like the overlay idea could be implemented more simply by taking advantage of the VM system: make part of the kernel code pageable. Memory formerly occupied by rarely used kernel code can then be used by userland applications. You will need some sort of backing store where the kernel code can be read after booting; this is not normally available. However, almost no kernel code is safe in a situation where an instruction fetch may fault. Reading or writing the secondary storage can easily cause a deadlock. It causes the thread to sleep, which is not allowed while holding a mutex. It would help if you could wire down pieces which will need to be used in the near future from a place where a fault is safe, but this may also be very slow even if the code is already in memory. Some other ideas for kernel size reduction: * Find pieces of code that are required but seem big for what they do for you, and try to make them smaller. The proposal should list concrete parts. * Find variables and functions that are required only during kernel initialization, place them in a special section and add this section to the free memory pool after kernel initialization. -- Jilles Tjoelker