From mint-bounce@lists.fishpool.fi Tue Aug 10 09:53:57 2010 Message-ID: <4C615968.6070600@atari-source.org> Date: Tue, 10 Aug 2010 09:51:36 -0400 From: Mark Duckworth User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: mint@lists.fishpool.fi Subject: Re: [MiNT] trunk-09082010 file structure / content 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On 8/10/10 8:32 AM, Miro Kropacek wrote: >> There is always going to be CPU specific options. MMU and FPU as well as >> different instructions. Choice is a fact of life. >> > Sure. But we can do it in runtime -- is there an FPU present? Yes, > initialize it. Same for MMU, exotic HW, anything. Only CPU specific > thing is stack frames and maybe some other Supervisor stuff, here are > changes for each new generation and this can be certainly solved by > some function pointers. > > Remember, there are three things we are discussing: > > 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. > > 2. Building the kernel (unified or not), in a way one specify only one > common CFLAGS and all parts will be compiled in one common way -- I > assume you agree this is good and welcomed? How it will be implemented > depends on 1.) > > 3. How many kernels to release. Depends a little on 2.) but you're > virtually free to release any CFLAGS combination you want. Here I > suggested we should, regardless on 1.) and 2.), release as few kernels > as possible, you don't share this point of view, I assume I have to > learn to live with that :) > > Btw, what others think? Is it better to provide kernel for each > machine/cpu combination than having some basic configurations ? > > I enjoy the concept of "fat" binaries. As long as the detection and initlialization code doesn't sit around in ram long after it's done I agree with the idea. I often wonder if that's a big reason for the mint (ram) bloat (and I use that term relatively because 2MB isn't too crazy) is that a lot of detection and initialization routines that run once are sitting in ram and can these not be unloaded in some way. Thanks, Mark