+++ 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/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
