From mint-bounce@lists.fishpool.fi Tue Aug 10 08:55:42 2010 X-Virus-Scanned: amavisd-new at demon.co.uk Subject: Re: [MiNT] trunk-09082010 file structure / content From: Alan Hourihane To: Miro Kropacek Cc: Helmut Karlowski , mint@lists.fishpool.fi 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> Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Aug 2010 13:53:28 +0100 Message-ID: <1281444808.3015.85.camel@jetpack.demon.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 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: alanh@fairlite.co.uk Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On Tue, 2010-08-10 at 14:32 +0200, 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. Now we are getting closer together. Using the MiNT loader approach, it is a runtime approach but there are more binaries around to load. With a huge monolithic kernel with differing codepaths for different CPUs we end up with a bigger single kernel that has optimizations built-in. I'd be o.k. with that, but I think that's probably a longer term goal as we'd have to make sure we unload/free code that isn't going to be used on the target CPU. > 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. As above. I think the MiNT loader is a good first step and with minimal turmoil to implement. A unified kernel has much more impact we could schedule for a 2.0 MiNT release. > 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.) We may need to build the same function with differing CFLAGS and use function pointers to implement codepaths and free unused code. I'm happy with that. > 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 :) I think it's easy to ship many kernels and get a MiNT loader to do the hard work. It's also pretty easy to implement within a short timescale. > Btw, what others think? Is it better to provide kernel for each > machine/cpu combination than having some basic configurations ? I'm happy with a unified kernel longer term, with optimized code compiled in at runtime and chosen, ensuring we release unused code/memory back to the system. Alan.