ARM as primary Architecture
Summary
Make ARM a primary architecture. add armv7hl to the i686 and x86_64 as arches that we build every package for. This will mean that all packages supported by the ARM architecure must build for ARM to be released. As of Fedora 19 we have dropped support for software floating support so we are only talking about adding hardware floating point 32 bit support (ARMv7 hfp 32bit).
Owner
- Name: Dennis Gilmore, Peter Robinson
- Email: dennis@ausil.us pbrobinson@gmail.com
- Release notes owner:
Current status
- Targeted release: Fedora 20
- Last updated: 2013-07-02
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
The Changing IT landscape has started to focus on greener technologies. One thing thats changing due to this is that ARM cpu's traditionally the domain of embedded and mobile applications are finding themselves moving into the desktop, notebook and server markets. Fedora ARM works on many different devices.
For this change we will enable armv7hl builds on primary koji, and compose arm trees alongside of x86 ones. Fedora has in the Phoenix data centre 96 quad core calxeda server nodes each had a quad core 1.4ghz soc, 4gb ram and 250gb hdd. Some of these nodes will remain in the arm koji for building updates for fedora 18 and 19 though when support for Fedora 18 drops some of the nodes will be able to be reallocated. Infrastructure has expressed an interest in trying some of its workloads on ARM, some are for QA, some for releng, there is currently 24 nodes configured in primary koji ready to go as builders, we can add 24 more when ARM becomes primary if desired.
we have moved the kernel to a unified kernel we now build a LPAE and base variant, the same as i686. There is a ARM specific kernel maintainer working in the fedora Kernel team. Release's are composed using the exact same tooling as primary. Disk images for development boards are generated by appliance-creator and the kickstarts live in spin-kickstarts, they take the same shape as livecds on primary but are shipped as a oem disk image, where initial-setup is used to do final user configuration. pungi generates a install tree the same as it does for primary, we are creating pxe install trees only as u-boot does not understand isofs.
Benefit to Fedora
Enables fedora to embrace the emerging arm world. There is currently servers and desktop like systems that can be used to run Fedora on. ARM systems use very little power, the OLPC XO 1.75 and newer devices are all arm based. Calxeda based servers are shipping today. We could look at having tablet spins in the future but that is currently outside the scope of this Change. By adopting this change we will be embracing the future. There is a lot of arm based setup box and HDMI dongle systems that have support landing in the upstream kernel. We can enable support as upstream support lands, allowing us to have a large number of ARM systems that are affordable and can run Fedora.
Scope
Add armv7hl to list of arches for f20-build and future build tags in koji compose armhfp trees with i386 and x86_64 Build hardware already exists in phx2 and is configured to talk to koji.
- Proposal owners: change the arches in koji, import the matching rawhide builds into koji. update release Engineering scripts to automatically build armhfp trees along with i386 and x86_64
- Other developers: submit builds as normal, in the event of unexpected build failures talk to the arm team to help debug and fix issues
- Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are the people proposing the Change.
- Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji
Upgrade/compatibility impact
systems running Fedora 18 or 19 should be upgradeable in the same way as x86 systems are.
How To Test
there are many different test vectors, most visible to developers will be that when they submit a build a armv7hl build happens also. Any supported arm system should work as it does today for ARM as a secondary arch.
User Experience
User experience does not change. The only difference will be the path in which they use to download files from on the mirrors.
Dependencies
There are no special depeendencies. Hardware in Phoenix is already installed, there is release engineering boxes for doing composing on, there is hardware available for QA use.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) if for some reason we fail horribly at migrating into primary we would go back to secondary, the fix would be removing armv7hl from the build arches by Release Engineering
- Contingency deadline: Alpha
- Blocks release? Yes