Date: Mon, 08 Apr 2013 17:34:55 -0700 From: Alfred Perlstein <bright@mu.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-hackers@freebsd.org, Amit Rawat <aamitr4@gmail.com>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: GSOC 2013 project " Kernel Size Reduction for Embedded System " Message-ID: <5163622F.60604@mu.org> In-Reply-To: <CAJ-VmonVre%2BVT2tTdQf3hA6DvKifqrJtxDT1RX8KEyW6a-=EXQ@mail.gmail.com> References: <CAOhv3dpTM9J9oiLpdw8xOAToXT_tQ3VW4Mv1F%2B8n7xhG%2BJK93w@mail.gmail.com> <20130408224423.GA64696@stack.nl> <CAJ-VmonVre%2BVT2tTdQf3hA6DvKifqrJtxDT1RX8KEyW6a-=EXQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/8/13 4:10 PM, Adrian Chadd wrote: > Hi, > > Your idea is interesting, but it doesn't fix the underlying problem - > there's just too much code. :( > If you were to API'ify some of the more basic things such as fget, fdrop, filedesc stuff you could potentially swap out the systems for simpler (albeit less efficient) algorithms, the cost there may be slow smp performance, or maybe not allowing threads? What we really need is someone to pin down those parts of code that smaller systems may not need and provide compromise when we remove them. Other ideas are simple like for instance removing certain syscalls (for example, more recent ones such as openat) and features such as unix descriptor passing. However, until a bunch of embedded folks come forward and state what they are really willing to sacrifice, then we won't really have anything to go on, and it will be guessing at what will work for a space that not all of us are familiar with. So I'm hoping some people can make the tough call to give direction here, otherwise nothing good will come of it. Has anyone actually done this? Or maybe compared against another embedded OS? -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5163622F.60604>