From Fedora Project Wiki
m (formatting)
(First draft)
Line 1: Line 1:
= Introduction =
= Introduction =
ARM processors are the most popular CPUs in the world.  While historically found in embedded devices, ARM systems suitable for general purpose computation are becoming increasingly common.  As ARM based laptops and desktops become people's everyday devices it is important that Fedora be available and well supported.  This page contains the rationale for promoting ARM to a primary architecture.  We include suggested criteria for evalauting this proposal as well as the technical and administrative steps that might be taken to ensure a smooth transition.
ARM processors are the most popular CPUs in the world.  While historically found in embedded devices, ARM systems suitable for general purpose computation are becoming increasingly common.  As ARM based laptops and desktops become people's everyday devices it is important that Fedora be available and well supported.  This page contains the rationale and scope for promoting ARM to a primary architecture.  We include suggested criteria for evalauting this proposal as well as the technical and administrative steps that might be taken to ensure a smooth transition.


= Criteria =
= Scope of ARM support propsal =
* Readily Available Hardware
While there are many ARM devices in the world, only a small subset of those devices are immediately suitable for use with Fedora.  Fedora on consumer electronic devices, though interesting, is beyond the scope of this proposal.  The goal herein is to mainstream the building of Fedora packages.  As such, ARM systems which are suitable for building packages are of primary interest.  There are no commercially available enterprise ARM servers at this time, but both [http://www.calxeda.com/ Calxeda] and [http://www.marvell.com/ Marvell] will enable OEMs to provide Enterprise grade ARM servers in the near future.  Other ARM semiconductors such as [http://www.apm.com/ Applied Micro] have announced the upcoming availability of 64-bit ARM Server CPUs as well.  This proposal begins the transition from Secondary to Primary with hobbyist boards, but includes and requires the use of Enterprise class hardware as one of the steps to a complete transition to Primary.
* Strategic value, alignment with Fedora goals
* Proof of concept as a secondary arch


= The Argument For and Against =
= Fedora ARM Today =
* The reason PPC was demoted is the same reason ARM should be promoted
Fedora ARM is currently a secondary architecture maintained by [http://zenit.senecac.on.ca/wiki/index.php/Main_Page The Seneca Centre for Development of Open Technology].  Seneca hosts its own koji-hub and dozens of ARM builders.  A second set of builders is provided by Red Hat, also using the Seneca koji hub.  Koji-shadow is being used to closely follow rawhide development. Most packages build for ARM with little to no modification.
* Builders are individually slower, but in aggregate can complete rebuilds faster
* What is Fedora? NetworkManager, SELinux, Pulse Audio, Systemd, gnome-desktop, these are all things * which work on ARM today.


= The argument against, with rebuttals =
Current ARM hardware is 32 bit, contains 512-1024MB of RAM, featuring single or dual core 1GHz processors.  Currently employed builder hardware is currently a combination of [http://pandaboard.org/ Pandaboards], [http://www.globalscaletechnologies.com/t-guruplugdetails.aspx Guruplugs], [http://trimslice.com/web/ Trimslices], and a few other miscellaneous host-types.  Server grade ARM hardware is not available commercially, but will be in the near future. The Enterprise grade server hardware to replace these systems will be quad core, have 4-8GB of RAM and run between 1.0-1.6GHz.
* Kernel not standardized: But only a small subset of ARM systems must be supported at first.
* Slows down x86_64 build speed: Compare build times
* Adds burdon to packagers: Packages that do not currently work with ARM will be excludearched, ARM team to work with maintainers to fix issues.
* LSB does not exist, but ARM does not need it.


= The Plan =
Moving from a secondary to a primary architecture in Fedora is unprecedented.  We propose a multi-step process where each step is small, reversible, and well timed to minimize impact on schedules, systems, and packagers.


= Steps To Primary =
* 1. Fedora 17 GA is complete.  Nothing happens during the critical part of the release cycle.
* Begin by moving koji services to colo facility
* 2. ARM Koji-hub service moves from Seneca to primary PHX Colo facility.  ARM builds are not yet tied * to any primary architecture, they are simply hosted by the same hub.  Builders at Seneca and Red Hat * communicate with the hub via proven proxy server.
* Drive builds from Koji during F18 rawhide cycle
* 3. Server-grade ARM hardware is introduced at Seneca or Red Hat, also communicates with PHX koji-hub via squid proxy.  Administrative obstacles are identified and resolved with vendors.
* Once server hardware is available for PHX, switch over for F18 final
* 4. Reliable server-grade ARM hardware is moved to the PHX Colo facility, communicates on local network with the official koji-hub.
* 5. Any packages that fail to build on ARM are marked with excludearch by a provenpackager.
* 6. Fedora 18 Branches
* 7. Proxy builders at Seneca and Red Hat are disabled, leaving only PHX ARM systems active.
* 8. A mass rebuild of F18 demonstrates capacity of Colo ARM servers to handle a complete rebuild in acceptable time period.
* 9. ARM is added to primary arch list for F18 GA.  If point 8 does not succeed more systems are added and this item pushes back to F19/rawhide.


= Package Set Support =
= Hypothetical Q&A =
* All packages build or are excludearched
* Functionality may vary according to platform
* A package need only build, not function fully, to not interfere with other packages.


= Evidence for viability =
* Q. Does Fedora ARM have a proven track record?
* Build history shows near-concurrent release with primary
** A. Fedora ARM has been has attained a significant degree of functionality in recent years using standard Fedora releng mechanisms such as rpm, mock, and koji.
* ARM support will not significantly slow down primary builds
* Similarity in critical-path package set demonstrates multiarch problems sooner


= Installation =
* Q. Do we have to support every ARM device on the planet?
* CD-ROM style install not needed
** A. No, only the subset of packages needed for builders needs to be supported at the outset.  Special graphics, custom mobile devices, etc, are not the subject of this proposal.
* Official rootfses initially
 
* Network and USB install with anaconda eventually
* Q. Will making ARM a primary architecture cause a sudden burden on packagers?
** A. No- Packages which do not work on ARM will initially be excused with excludedarch.  Members of the ARM team will work with packagers to get their packages working on ARM.  Most packages already work with ARM so the actual effort to get to this point is relatively minor.
 
* Q. Will making ARM a primary architecture slow down builds significantly?
** A. No- Part of the proposal is to bring up as many ARM servers as it takes to provide the processing capacity needed to complete a mass rebuild in a similar period of time.  At present we believe 3 server-grade ARM systems for 1 x86_64 system will provide comparable build power.  Should this number be insufficient we will add builders until the required build power is reached.
 
* Q. Do all packages need to work on ARM?
** A. No- they only need to build or be excludearched.  For primary purposes it is imperative that we minimize the impact on other architectures.  After build system integrity has been assured, individual packages can be tested and fixed as needed.
 
* Q. Are there any benefits to Fedora users and developers who don’t care about ARM?
** A. Yes- Bugs are sometimes exposed by ARM before they are observed on other architectures.  Adding ARM to primary will enable us to spot bugs sooner, not just on ARM, but for many classes of architecture-neutral bugs.
 
= Differences between ARM and x86 =
In one sense, Fedora is a collection of Linux packages, managed by RPM with a selection of very specific features provided by NetworkManager, SELinux, Pulse Audio, Systemd, gnome-desktop, etc.  These are all packages which Fedora ARM supports today.  There are some differences, however, when one approaches the installation of new systems.
 
There is not a unified kernel for all ARM systems as there is for all x86 systems.  This is slowly changing as more ARM systems move to Flattened Device Tree.  Nonetheless, the initial kernel package for ARM will only support a small subset of available ARM systems.  While we want to be as inclusive as possible, for the Primary push, only certain devices will be supported via the official kernel package.  It is possible and likely that additional kernels will be built along-side to provide additional support.
Installation via CD-ROM is not available as no ARM systems come with optical drives. Installation via USB stick, though possible, is a bit trickier due to the non-unified kernel.  PXE and full Anaconda ARM support are both possible, though in their infancy.
There is no LSB for ARM, yet, but it’s entirely functional without LSB.
The critical path package set is actually almost identical.
 
= Why leave secondary? =
 
One might wonder, since ARM is not yet at full feature parity of x86_64, why should it be promoted?  The answer is that the primary vs secondary distinction isn’t simply about competing architectures, it’s about a smooth running project.  Consider the reason PowerPC was demoted to a secondary architecture:
 
PowerPC was dropped by Apple, removing the primary supplier of PPC hardware from the market.
With each passing month, fewer developers had PowerPC hardware, decreasing interest in its support.
Even with interest in the platform, hardware for building and using Fedora PPC was harder to come by.
Rare hardware and slight interest made PPC bugs a significant drag on Fedora as a whole
 
In contrast, ARM systems are ascending in the market place.  There is inexpensive hardware readily available, soon for as little as $35.  There will be an excess of package builders by the time the final step in the primary push is complete, dwarfing even x86_64 in machine count and possibly in mass rebuild time.  This low barrier to entry means more people than ever, around the world, can afford to be part of the Fedora Project.

Revision as of 05:25, 2 February 2012

Introduction

ARM processors are the most popular CPUs in the world. While historically found in embedded devices, ARM systems suitable for general purpose computation are becoming increasingly common. As ARM based laptops and desktops become people's everyday devices it is important that Fedora be available and well supported. This page contains the rationale and scope for promoting ARM to a primary architecture. We include suggested criteria for evalauting this proposal as well as the technical and administrative steps that might be taken to ensure a smooth transition.

Scope of ARM support propsal

While there are many ARM devices in the world, only a small subset of those devices are immediately suitable for use with Fedora. Fedora on consumer electronic devices, though interesting, is beyond the scope of this proposal. The goal herein is to mainstream the building of Fedora packages. As such, ARM systems which are suitable for building packages are of primary interest. There are no commercially available enterprise ARM servers at this time, but both Calxeda and Marvell will enable OEMs to provide Enterprise grade ARM servers in the near future. Other ARM semiconductors such as Applied Micro have announced the upcoming availability of 64-bit ARM Server CPUs as well. This proposal begins the transition from Secondary to Primary with hobbyist boards, but includes and requires the use of Enterprise class hardware as one of the steps to a complete transition to Primary.

Fedora ARM Today

Fedora ARM is currently a secondary architecture maintained by The Seneca Centre for Development of Open Technology. Seneca hosts its own koji-hub and dozens of ARM builders. A second set of builders is provided by Red Hat, also using the Seneca koji hub. Koji-shadow is being used to closely follow rawhide development. Most packages build for ARM with little to no modification.

Current ARM hardware is 32 bit, contains 512-1024MB of RAM, featuring single or dual core 1GHz processors. Currently employed builder hardware is currently a combination of Pandaboards, Guruplugs, Trimslices, and a few other miscellaneous host-types. Server grade ARM hardware is not available commercially, but will be in the near future. The Enterprise grade server hardware to replace these systems will be quad core, have 4-8GB of RAM and run between 1.0-1.6GHz.

The Plan

Moving from a secondary to a primary architecture in Fedora is unprecedented. We propose a multi-step process where each step is small, reversible, and well timed to minimize impact on schedules, systems, and packagers.

  • 1. Fedora 17 GA is complete. Nothing happens during the critical part of the release cycle.
  • 2. ARM Koji-hub service moves from Seneca to primary PHX Colo facility. ARM builds are not yet tied * to any primary architecture, they are simply hosted by the same hub. Builders at Seneca and Red Hat * communicate with the hub via proven proxy server.
  • 3. Server-grade ARM hardware is introduced at Seneca or Red Hat, also communicates with PHX koji-hub via squid proxy. Administrative obstacles are identified and resolved with vendors.
  • 4. Reliable server-grade ARM hardware is moved to the PHX Colo facility, communicates on local network with the official koji-hub.
  • 5. Any packages that fail to build on ARM are marked with excludearch by a provenpackager.
  • 6. Fedora 18 Branches
  • 7. Proxy builders at Seneca and Red Hat are disabled, leaving only PHX ARM systems active.
  • 8. A mass rebuild of F18 demonstrates capacity of Colo ARM servers to handle a complete rebuild in acceptable time period.
  • 9. ARM is added to primary arch list for F18 GA. If point 8 does not succeed more systems are added and this item pushes back to F19/rawhide.

Hypothetical Q&A

  • Q. Does Fedora ARM have a proven track record?
    • A. Fedora ARM has been has attained a significant degree of functionality in recent years using standard Fedora releng mechanisms such as rpm, mock, and koji.
  • Q. Do we have to support every ARM device on the planet?
    • A. No, only the subset of packages needed for builders needs to be supported at the outset. Special graphics, custom mobile devices, etc, are not the subject of this proposal.
  • Q. Will making ARM a primary architecture cause a sudden burden on packagers?
    • A. No- Packages which do not work on ARM will initially be excused with excludedarch. Members of the ARM team will work with packagers to get their packages working on ARM. Most packages already work with ARM so the actual effort to get to this point is relatively minor.
  • Q. Will making ARM a primary architecture slow down builds significantly?
    • A. No- Part of the proposal is to bring up as many ARM servers as it takes to provide the processing capacity needed to complete a mass rebuild in a similar period of time. At present we believe 3 server-grade ARM systems for 1 x86_64 system will provide comparable build power. Should this number be insufficient we will add builders until the required build power is reached.
  • Q. Do all packages need to work on ARM?
    • A. No- they only need to build or be excludearched. For primary purposes it is imperative that we minimize the impact on other architectures. After build system integrity has been assured, individual packages can be tested and fixed as needed.
  • Q. Are there any benefits to Fedora users and developers who don’t care about ARM?
    • A. Yes- Bugs are sometimes exposed by ARM before they are observed on other architectures. Adding ARM to primary will enable us to spot bugs sooner, not just on ARM, but for many classes of architecture-neutral bugs.

Differences between ARM and x86

In one sense, Fedora is a collection of Linux packages, managed by RPM with a selection of very specific features provided by NetworkManager, SELinux, Pulse Audio, Systemd, gnome-desktop, etc. These are all packages which Fedora ARM supports today. There are some differences, however, when one approaches the installation of new systems.

There is not a unified kernel for all ARM systems as there is for all x86 systems. This is slowly changing as more ARM systems move to Flattened Device Tree. Nonetheless, the initial kernel package for ARM will only support a small subset of available ARM systems. While we want to be as inclusive as possible, for the Primary push, only certain devices will be supported via the official kernel package. It is possible and likely that additional kernels will be built along-side to provide additional support. Installation via CD-ROM is not available as no ARM systems come with optical drives. Installation via USB stick, though possible, is a bit trickier due to the non-unified kernel. PXE and full Anaconda ARM support are both possible, though in their infancy. There is no LSB for ARM, yet, but it’s entirely functional without LSB. The critical path package set is actually almost identical.

Why leave secondary?

One might wonder, since ARM is not yet at full feature parity of x86_64, why should it be promoted? The answer is that the primary vs secondary distinction isn’t simply about competing architectures, it’s about a smooth running project. Consider the reason PowerPC was demoted to a secondary architecture:

PowerPC was dropped by Apple, removing the primary supplier of PPC hardware from the market. With each passing month, fewer developers had PowerPC hardware, decreasing interest in its support. Even with interest in the platform, hardware for building and using Fedora PPC was harder to come by. Rare hardware and slight interest made PPC bugs a significant drag on Fedora as a whole

In contrast, ARM systems are ascending in the market place. There is inexpensive hardware readily available, soon for as little as $35. There will be an excess of package builders by the time the final step in the primary push is complete, dwarfing even x86_64 in machine count and possibly in mass rebuild time. This low barrier to entry means more people than ever, around the world, can afford to be part of the Fedora Project.