Re: armelfp: new architecture name for an armel variant
+++ Bill Gatliff [2010-07-10 21:05 -0500]:
>
> I would suggest to pick a generic, short name, with we could reuse
> later if it is proven that hardfloat has no sense in the next years.
> Comments?
I don't think you can re-use Debian arch names. They mean something
and if it's been used at all widely you can't just change it later (or
at least not for 10-20 years or so). (armeb was little-enough used
that we probably could change it).
> I don't see them all becoming official Debian ports, but it would be awfully
> nice to someday have several repositories to choose from depending on whether
> you want least-common-denominator Debian for ARM, packages that have been built
> with compiler optimizations for Cortex A8, or XScale, or whatever. And then
> big/little-endian, EABI/OABI, SMP, and whatever else comes along later.
Yes, this would be nice, by some mechanism or other. It's currently
harder than is helpful.
> I think the howls of maintenance protest are somewhat justified, but you just
> can't go wrong with names like "arma8vfpel", "arm920tel", and so on. >
> It would be really cool if we could find a way to make it easy to launch a
> buildd to create packages for, say, "A8 with VFP and EABI",
You are conflating ABI with optional build/instruction set features.
Debian arches should be reserved for _incompatible_ ABIs (OABI, EABI
hard-float, EABI softfloat). With/without VFP and cortex A8
optimisations is not incompatible - it's orthogonal. Each Debian arch
has a _default_ for those (which can change over time as i386 used to
be built for i386, then i486, now i586).
Encoding those flavours/build options in the (incompatible ABI) 'Arch'
name is the wrong way to go (IMHO). It's too heavyweight and intrusive and
you get get alphabet soup. We should use other mechanisms to build and
select optimisations and instruction-set extensions (at either
install-time or runtime, maybe both).
The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
NEON) and instruction set versions (v4, v5, v6a, v7) can also be
incompatible in the sense that they won't run on hardware without
those features. But I really think we should try to deal with that by
correctly decorating ELF headers and making sure that the loaders and
dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch
for every combination.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: