From mint-bounce@lists.fishpool.fi Tue Aug 10 09:12:14 2010 X-Squirrel-UserHash: EhVcX1lFRQVaRwYcDQ== X-Squirrel-FromHash: UANfXlsTQ1M= Message-ID: <76cc489f13855a957a1445481e9eebb8-EhVcX1lFRQVaRwYcDTpQCEFddQZLVF5dQUNBAjBTXF5bVkYPWkF3AVM6XF1XQEEGWl1QQA==-webmailer1@server02.webmailer.hosteurope.de> In-Reply-To: References: <1281383933.4401.87.camel@jetpack.demon.co.uk> <1281387993.4401.164.camel@jetpack.demon.co.uk> <1281389959.4401.204.camel@jetpack.demon.co.uk> <1281398029.4401.343.camel@jetpack.demon.co.uk> <1281425999.4401.816.camel@jetpack.demon.co.uk> <1281438486.4401.1029.camel@jetpack.demon.co.uk> <1281442675.3015.43.camel@jetpack.demon.co.uk> Date: Tue, 10 Aug 2010 15:09:50 +0200 Subject: Re: [MiNT] trunk-09082010 file structure / content From: "m0n0" To: mint@lists.fishpool.fi Reply-To: ole@monochrom.net User-Agent: Host Europe Webmailer/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-HE-Access: Yes X-bounce-key: webpack.hosteurope.de;ole@monochrom.net;1281445790;b7695204; X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: ole@monochrom.net Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Am Di, 10.08.2010, 14:32 schrieb Miro Kropacek: > 1. Unified kernel (where applicable/possible) -- would you accept such > patch? If not -> I stick to the solution with mint loader, if yes, I > start working on merging. To me there is just one answer to this question: Performance. Use the method that __allows__ to get the most out of the hardware, with minimum size. But anyway I can't see why different kernel builds ( for 000, 030 etc.) shouldn't be used with an unified kernel approach... I like to have an kernel that is compiled for my specific processor. And I like to have it small. And I think it's not so good to have code in kernel that is never ever used... And I like to have kernel modules which are also compiled for my specific processor. Maybe using some kind of combination of CFLAGS, dynamically selected functions available from unified kernel, and Configuration flags will be the solution? Then there would be 2 ways to influence the kernel / module build: Modifying CFLAGS Modifying Configuration Flags What I don't like: When something restricts me from building an fine grained kernel. If FreeMiNT had some more users I would say: providing a bunch of suitable kernels is up to the distribution maintainer... this kernels could be selected dynamically by an installer for that distribution. -- Greets, m0n0