[fedora-arm] ARM Primary FESCO discussion results, round 1

[Chris Tyler]

First stab at a few answers--

On Mon, 2012-03-19 at 16:46 -0700, Brendan Conoboy wrote:
> How are ARM-specific issues such as legacy alignment problems to be 
> addressed?

ARM v7 systems have hardware fixup for alignment issues, just as x86
does. ARM v5 systems can do fixup in software with a CPU trap at a small
performance cost. (Note: there is a performance cost for hardware fixup,
even on x86 systems)

> How do packagers test and resolve failures on ARM if they don't own an 
> ARM device?

There are several solutions available:

1. They can use emulation. Fedora already includes a good-quality ARM
emulator (qemu-system-arm) that provides decent performance; we can
package ready-to-run ARM images for that emulator. (This emulator can
provide Kirkwood execution speeds on a modern x86 PC).

2. ARM computers can be bought for as little as $35 (the Raspberry Pi).

3. Packagers can use Koji for remote scratch builds (just as someone who
only has 32-bit x86 can use Koji for 64-bit x86 builds).

4. We could consider setting up remote access to ARM systems (though
this doesn't provide a lot of benefit over option 1 in most cases).

> When will server hardware be available?

Real Soon Now(tm)!

How about "We anticipate early availability of ARM server systems in the summer of 2012."

> Why isn't being a secondary architecture good enough?

1. The user base is expected to grow to substantial numbers quickly. It
is important to provide this user base with timely security updates and
fixes, which can happen much more readily in primary arch than in
secondary (which, even in the best case, lags behind PA).

2. As innovators in open source, we have an opportunity to take a
leadership position by providing first-class support for emerging
platforms such as the OLPC XO 1.75 and 3.0, the Raspberry Pi, and
upcoming very-environmentally-friendly enterprise-class server systems,
each of which supports an admirable goal.

3. The differences between ARM and x86 are not huge, and therefore cost
of supporting ARM as a primary arch is not very high. ARM is
little-endian (like x86), and nearly all of the libraries and languages
in Fedora now support ARM (very different from even a few releases ago).

(Needs strengthening)

> Why not wait for 64 bit ARM?

64 bit ARM is years away from general availability, let alone widespread
use. Fully supporting 32-bit ARM now puts us in a solid position to
support 64-bit enterprises systems as they appear.

> With there being so many different kernel variants, how will a kernel 
> build complete in a reasonable period of time?
> 
> The builds being done in Koji are great, but what is the plan for 
> composes, QE and installation?

Rootfs composes will be automated in much the same way that x86 spin
composes are now automated. QE and installation will be different but
not vastly more complex than in the x86 realm.

(I think that we should explain the ARM install situation in terms of
live image spin composes, because these have the greatest similarity --
the package selection is preset and not alterable during installation,
for example).

> If Anaconda isn't used to do installations, what will be doing the 
> things Anaconda does which just installing a bunch of packages doesn't? 
> (I don't know what these are)

These include:
- setting up the partitioning
- (in some cases) setting up the network configuration
- setting the root password
- selecting the timezone
- selecting the locale and keyboard layout
- (package selection, which does not apply to x86 live images)

Several of these will need to move from Anaconda to firstboot (we're
already working firstboot modules for a few of these for the Raspberry
Pi).

> Will there be extra patches in the kernel to enable new vendors' ARM 
> processors or will upstream continue to be the way?
> 
> What does the kernel team think about the the time required to build 
> kernels on ARM? How will it affect their workflow?

Question: do we need to do a fully-clean build for each ARM SoC variant?
Or can we do the machine and config changes for each and then make? The
difference in time could be huge.

> The proposal suggests building just a versatile express kernel by 
> default (to save time), then using koji flags to support alternate 
> kernels.  Is this possible?

I think a better question is: Is this wise? This would mean that the
majority of the ARM kernels won't be built or tested by default.

(Also, do we mean "Koji flags" or do we mean "editing the spec file to
set macro values"?)

> In the event that kernels are built separately per the above, what 
> mechanism will be used to keep the kernels in sync?
> 
> 
> 
> Assertions from the meeting:
> 
> There must be a commitment of hardware both for build systems and test 
> systems for PA.
> 
> Being a PA carries the obligation that all packages in Fedora will be 
> available.  The proposed avenue of making broken packages temporarily 
> excludearch is questionable and needs work.
> 
> FTBFS issues should simply be fixed (That's not an ARM problem, but 
> we're definitely impacted by it).
> 
> The changes to QE, particularly because of Anaconda, will be 
> substantial.  This is not addressed in the proposal.
> 
> Installability doesn't necessarily mean Anaconda (See EC2), but it does 
> mean something.  A real plan is called for.
> 
> All PA kernels must be derived from the same source rpm.

This is what we're proposing.

> 
> That's it for now- I'll reply later with my own thoughts on the above.