[Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)

[Dennis Gilmore]

Resending i posted to list from address not subscibed

On Friday, September 16, 2011 04:46:33 AM Panu Matilainen wrote:
> Oh I knew this would happen... the send-button is a magic
> memory-enhancer in disguise. One (of probably many) forgotten bits, this
> 
> time hopefully with working address for Dennish too:
> > On 09/15/2011 01:55 PM, Jon Masters wrote:
> >> All of the existing stuff assumes that if we have vfpv3 on ARMv7 we're
> >> going to be running in hardfp. We can keep that notion around in the
> >> very short term, but we need a longer term solution. And although we
> >> don't necessarily plan actual parallel installs of different ABIs, it is
> >> not technically the case that all ARMv7 systems are going to be running
> >> the hardfp port. We may e.g. install an ARMv5 port therein.
> 
>  From what I've heard + read about the hardfp ABI, its not actually
> possible to parallel-install with anything else because even the dynamic
> linker has no clue whether hardfp or some other ABI was used (see
> http://wiki.debian.org/ArmHardFloatPort/VfpComparison, cheers to our
> friends over Debian side again for a nice article :) Which makes this a
> truly <cough> "unique" <cough> piece of work. I'd love to know why it
> was done that way - my layman sense thinks the compiler toolchain should
> be able to mark the ABI in the elf headers (heck this is what the whole
> hwcap thing is about).

 
> Since the ABI difference is apparently not recorded anywhere, there's
> little chance of rpm being able to automatically do the right thing
> really, and I dunno if its worth it trying to jump through a whole lot
> of hoops for what seems an unachievable task.
> 
> One simple brute-force "solution" that should work right now is to just
> keep the softfp/hardfp "architectures" incompatible from rpm POV and
> make the assumption that hardfp ABI will be used if the system is
> capable of it. And if somebody wants to override this assumption, that's
> what /etc/rpm/platform is for (allow overriding rpm's hw detection).

im not the biggest fan of this,  Maybe we can hard code it somehow at 
compilation time? as well as extend rpm-python to be able to expose it so yum 
can do the right thing. we have no plans to support multi-arch here, and 
anaconda (which we dont have yet but is underway) doesnt write out a 
/etc/rpm/platform file any longer. ive not looked to see if that code is 
removed from anaconda or just disabled.  our plan is if you install a softfloat 
on the system thats all you can run.  and same for hardfloat.  while the 
buildsystem will have v7 builders that are building for v5 and therfore 
running softfp, most people should be running the hardfp port since its in the 
order of 300% faster for floating point operations. the only common case of 
softfp use i see on v7 hardware is those already running it. 

Ill revise my patch to use hwcaps rather than reading /proc/cpuinfo id really 
like to wrap the code path around something define or something set when we 
build for armv7hl

> Of course the entire hw-detection and arch-compatibility system is
> seriously outdated and inadequate for todays needs, back in the nineties
> systems were a lot less schizophrenic :) I've various vagueish ideas in
> this area, but the current concept of "arch" is built so deep into tools
> around rpm that fundamentally changing it is likely to be a long and
> hard road.
rather than having yum do its own arch detection it should be able to grab it 
from rpm that way both tools use the same code path and will always give the 
same result.


We also have an issue where we are setting the isa to the <arch>-32  we really 
should use arm-32 and armhfp-32 or armhf-32  that way the sub arches  can be 
used correctly.  some packages especially in the softfloat port could do with 
having additional arches built. pixman for example could do with armv6l and 
armv7l builds on softfp. 

yum has its basearch variable that it uses which currently is arm for all arm 
arches but should be armhfp for the new abi,  I do think that the best way to 
deal with the new abi is to treat it as a new seperate arch.  not sure if 
thats true of the new x86 abi.

Dennis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20110916/3856ae40/attachment.asc>