Re: [MiNT] trunk-09082010 file structure / content

[Alan Hourihane <alanh@fairlite.co.uk>]

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.