Re: armelfp: new architecture name for an armel variant
On Thu, Jul 08, 2010 at 01:06:58PM +0200, Guillem Jover wrote:
> Personally, before any further discussion I'd like to see some numbers
> with core libraries (libc, libgcc, libgmp, libatlas? etc) built with
> softfp, which eventually might be able to switch to use the hwcaps
> infrastructure in a similar way as how packages like libc6-i686 are
> handled.
The key limitation with hwcap approach is that it only extends to shared
libraries. Optimized binaries and plugins cannot be provided with hwcaps.
Things like libc-i686 are also problematic for endusers. How do I
quickly install all 686 optimized versions of libraries I already have?
> Adding a new (official) architecture variant is a huge overhead for
> everyone, it implies adding new porter boxes, patching packages (but
> hopefully not many) to handle the new arch, having someone handle the
> build daemons,
Adding a new arch creates a big overhead for *selected* people, rather than
everyone - most packagers in debian are unaffected. Multiple libraries
is not exactly zero-effort either, there could easily be hundreds libraries
we could want optimized. That is if we want to provide a *good* service
to users with VFP's rather than a lipservice. And we still wouldn't have
a vfp version of quake2.
> The lpia is a great example of an architecture variant that was a
> mistake, and should haver never been created.
LPIA was mainly a issue since people used it as "if arch=lpia then build
mobile ui". That prevented users from installing full versions of software
or trying mobile UI's in regular i386 installations.
If dpkg had subarchitecture support, lpia wouldn't have been as big
a issue. Ubuntu decided to shortcut and not add support for compatible
subarchs in dpkg, and the result was what it always is when people make
shortcuts...
Subarchs could also be useful if we wanted to build softfp abi compatible
armv6/armv7 armel builds of the whole debian repository. Of course we could do
builds without subarchs, but then users would be unable distinguish which
installed packages are for which cpu, and providing that via debian infra
would not be possible.
But the key difference with lpia and hardfloat armel is that they are not binary
compatible. And if we use it as a opportunity to target armv7+, do not really
share much of hardware either.
Reply to: