On Mon, Jul 12, 2010, Mark Mitchell wrote:
- Build a fully hard-float world (high effort - requires packing and
distro work to define and build a new armelfp port of the archive)
Since (2) and (3) are both high-effort, perhaps it would be better to choose one of the other approach for now, rather than attempting to do both initially.
I agree. And, for what it's worth, I would try to avoid (3) at almost all costs. One of the advantages of the ARM ABI and one of the objectives of Linaro is to provide a standard platform. Life as a Linux ISV is complex enough (multiple distributions, kernel versions, etc.) without also having to worry about the ABI. I think it would be better to do quite a bit of tools work than to fall back to the approach of a completely parallel distribution.
It's an appealing case which you make in favor of simplicity and universality, but I think this only covers half of our goals. We certainly aim at standardizing the platform, but we're also building higher-level tools to base on, extend, and derive that base platform. That is, I don't expect all products to ship based on the same standard platform; OEMs, ODMs, Silicon vendors, other folks will want: - to change sources (deviate/fork/etc.) - the smallest possible "disk" and memory footprint - the fastest as possible binaries - all of this for yesterday
So building a standard platform which will get good but not best results is useful, but we also need to provide Linaro's "end-users" with tools to get even closer to "best value" for them.
Perhaps it's possible to build a standard platform which always include two versions of functions, and to then /usr/bin/strip it down down the pipe -- but perhaps it's actually easier (less work) to maintain an ABI variant.
In any case, we weren't ready within Linaro to go out make such a port all by ourselves, because it didn't seem to bring much compared to other things we can work on, but we decided that if Debian was to do it, we should support them. So if you think it's not a wise move to invest their time into this new port, it would be good to speak directly to this group bringing your arguments forward. I think Debian rather than Linaro would be putting the biggest amount of work into a new armhf port, while it sounds like Linaro would be doing a non-trivial amount of complex work otherwise. I'm all for doing the thing which minimizes work for everybody overall (/if it gets us the "best" results/), but we need to align with Debian on such a plan.
There's the question of the timeline too: Debian folks are excited about doing (3) now, and it's within reach. How long will it take to get the toolchain able to do (2)?
Cheers,