[fedora-arm] Support for ARMv7, hardware math

omalleys at msu.edu omalleys at msu.edu
Wed Dec 1 19:37:58 UTC 2010


Quoting Andy Green <andy at warmcat.com>:

> On 12/01/10 18:37, Somebody in the thread at some point said:
>
> Hi -
>
>> I don't disagree with a split, but what concerns me is we don't have
>> enough resources to get F13-ARM out the door, much less two versions of
>> the distro. We don't have enough people nor the hardware to pull it off.
>
> Infrastructure evidently already exists to knock out armv5 packages.
>
>> If you can cross-compile, and knock out 50% of the bugs out in a
>> "pre-build" system before they hit the actual build system. It increases
>
> Several years ago I made my own rpm-based cross-build system similar  
> to this.  You meet packages like perl, which as part of its build  
> process created a "miniperl" that it then ran to complete the build  
> process. Except when you build cross, the miniperl executable is an  
> ARM executable on an x86_64 box and it can't complete the build  
> process.
>
> Most packages are not that tough but there are still enough funnies  
> that instead of knocking bugs out in some awesome fast cross  
> environment, you are running around discovering and solving  
> cross-specific bugs.

yuck. :P
>> the overall speed of development. I am fully aware it isn't going to be
>> simpler then using real hardware, but I was wondering if it would be
>> simpler then trying to get qemu-arm with virtio and the plan9 layer
>> working (i failed the first time).
>
> qemu arm is a dead loss for mass build, it's a fraction of the speed  
> of native execution on even a weak arm.
>
>> Distributing a VM "image" with all the build tools set up and everything
>> configured is a lot simpler then setting up a full blown dev environment.
>
> If it was the case that arm will never approach x86 speeds, then  
> cross is worth worrying about because it will solve years of speed  
> differential by a large effort now.
>
> But that is not the case, fast arm native platforms are already here  
> and will only get faster in the future.  Cross and arm emulation are  
> not the solution and won't become the solution either.

I was looking at today. Today the project has a handful of builders.  
How does the project get on track to appear to be a viable solution,  
rather then a secondary arch that is 2 releases behind to someone  
unfamiliar with the project?  What is the easiest way to get there  
today?






More information about the arm mailing list