Loïc Minier wrote:
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.
Sure -- but building a completely parallel distribution with a hard-float ABI is a big cost. It's going to cause anyone building an application binary or library to have to build it twice, validate it twice, etc. In the worst case, distributors will end up deciding they need to put both hard- and soft-float versions of libraries on their systems, so that they can run binaries built for both versions of the ABI, with attendant costs in terms of paging, flash usage, etc.
Before we decide that's necessary, someone should have some very good evidence that this is really useful. Right now, as far as I know, we don't.
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 don't know who the right people in Debian are; I'd rather suspect you're a lot more connected than I. :-)
There's the question of the timeline too: Debian folks are excited about doing (3) now, and it's within reach.
It's within reach, sure -- but it has big long-term costs. It's cheap to do because there's a button to press to build a new variant of all the packages. But, then you have two distributions to support forevermore, and a fragmentation cost for the entire ARM Linux community.
How long will it take to get the toolchain able to do (2)?
It would take months, but not years. It's going to take a few person-weeks to implement the source attribute. GLIBC is going to need to add new versions of libm functions that can be called with the hard-float ABI, while preserving the old soft-float versions using symbol versioning. GDB may need some work to handle the attribute. So, there's non-trivial work.
But, when you're done, you actually have the solution that you really want -- critical high-performance math functions can be called more efficiently, and nothing else is impacted.