On Mon, Jul 12, 2010, Mark Mitchell wrote:
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.
Yes; in fact, the lpia port in Ubuntu was painful for some of these reasons: - maintaining the port, buildds, update source packages for lpia, ... - validating twice - no ISV package (e.g. skype_i386.deb)
...but the biggest pain was its absence in Debian! This is an important point: what's not in Debian is pain to maintain, and a port even more so because it's all over the place.
People come to me and ask about building hard-float images; they believe it will be faster, and I can certainly imagine it will be, but it's not clear how fast; nevertheless they want the best. I can't suggest them to use the "armel" port for that, because it would mean the system would appear to be compatible with packages built for a different ABI -- the right way to do a .deb hard-float image is to use a different dpkg architecture name. But they can't do that because a new port is too much effort for their own project. Now I could also tell them that they could extend the toolchain and some libraries to achieve this, but again it's not something they can do right now nor undertake by themselves.
hard-float Debian port; pros: + motivated Debian people working on it now + toolchain can already do it + best possible binaries for hard-float systems
cons: - fragmentation - cost of maintaining the port
extension to the toolchain and some libs to support hard-float flavors of some functions; pros: + rips out biggest benefits of hard-float + single binary works on all systems; no fragmentation
cons: - not there yet and can't be done by the Debian people who would work on a new port - manual changes to libraries, only some libraries benefit ? more complex toolhain
The arguments in terms of disk and memory usage are pretty much the same I made :-) except I think the hard-float case is in a better place: its binaries will be just a bit smaller, and I don't see an issue with a vendor including a soft-float libc if that's what the vendor wants to do for maximum compatibility. This situation is similar to 64-bits system including a set of 32-bits libraries to run proprietary software; of course the 64-bits aren't usually challenged for disk space.
Perhaps one way to kill the size/memory discussion would be to have a mechanism to strip down the special double-ABI binaries, e.g. libm. Do you think this would be possible?
Also, why do we only consider libm / manual optimizations with source attributes? Wouldn't it be possible to apply this mixed-float approach to random C libraries automatically? I'd very much like this to be the case, because that would make it possible to use a "do mixed-float flavors" flag in gcc across a whole distro and worry about striping down the binaries later, either to tailor for hard-float or to tailor for soft-float; it would cover all libraries rather than manually optimized ones like libm and would make supporting these two flavors easier.
What I perceive as high risks: - doing a lot of work such as a new port or large toolchain developments, and then discovering they are not worth the gain (anymore) in some months; perhaps because the VFP unit has been improved substantially - doing the toolchain changes, but still seeing a measurable difference across hard-float and mixed-float worlds, because a bunch of small libraries use floats here and there
What I perceive as medium risk: - spending time doing these toolchain changes instead of more useful ones
I don't know who the right people in Debian are; I'd rather suspect you're a lot more connected than I. :-)
I am, but I don't like proxying arguments and I hate have both Linaro and Debian hats without real toolchain contributions to backup toolchain positions. I have background to comment on the pain of new ports for sure, but not in favor of the toolchain changes; and I would be perceived as biased if I were to recommend to Debian not to do anything right now and to wait for Linaro's new toolchain features in 6 months...