ARM as a primary architecture

[Jon Masters]

Hi again,

I want to thank you, and everyone else in FESCo for talking with us
yesterday, and for looking over the proposal. Bear in mind, it's a work
in progress. We intend to have broader conversations over the coming
months and F18 is an optimistic goal. Nonetheless, I feel it is
achievable (we've done many more disruptive things!) but we have also
many points along the way at which we can back out, and remain SA.

To address a few of these points...at least, I'll try :) First, just to
repeat, we took the proposal to FESCo yesterday in the spirit of "early
and often", not in the spirit of "final deliverable". Therefore, while
it is true we've not yet reached out to everyone for input, that is
because it is still a work in progress for us. We'll iterate based on
feedback, and based upon yesterday and reaching out to other groups.

On 03/20/2012 11:52 AM, Peter Jones wrote:

> 1) mechanisms need to be in place to get package maintainers access to fix
>     arm-specific bugs in their packages

So we have a tracker bug at the moment. Is that sufficient? If so, we
obviously should make sure that it is included in the proposal docs that
we have this in place and are using it.

> 2) excludearch is not an option.  This is fundamentally contrary to being
>     a primary arch. In fact this is one of the defining characteristics of
>     a secondary arch.

Let's think about this some. ARM (32-bit) doesn't do Intel-style
microcode, MCE, or many other things that x86 does. I don't think that
means we should build packages that are x86-specific for ARM systems. We
generally believe that we're starting from a point of good momentum, but
there are some packages that won't ever be appropriate for ARM, and
there are others where the FTBFS has been longstanding, or there are
other (IMO valid) reasons why it might initially be Exclude. That
doesn't mean that there would be many such cases. Nonetheless, I think
it would be unreasonable to set the entry bar so high that there can be
no things left to fix. That basically retains the x86 monopoly.

> 3) arm must be integrated to the formal release criteria

Agreed. We'll need to figure that out.

> 4) when milestones occur, arm needs to be just as testible as other
>     primary architectures

So we have a new hire (hi Paul) who is looking at autoqa, and we're
going to pull together as much as we can here. It would help me to know
(and we're reaching out to QE separately - per my other mail) what you
would consider "testable" to mean, in terms of what you'd want to see.

> 5) installation methods must be in place.  I'm not saying it has to be
>     using the same model as x86, but when we get to beta, if it can't be
>     installed, it can't meet similar release criteria to existing or prior
>     primary arches. Where possible, we should be using anaconda for
>     installation, though I'd be open to looking at using it to build installed
>     images for machines with severe resource constraints.

So we feel it more appropriate to use image creation tools at this
point, for the 32-bit systems that we have in mind. There will be
servers this year, but not yet, and they represent a small part of the
overall value of ARM to Fedora. When you have systems that cost more
than an order of magnitude less than their x86 brethren, that does mean
there are some implementation differences. For one thing, the reason
most of these boards are inexpensive is that they've done away with
dedicated flash on-board for U-Boot, etc. Instead, the SoC (chip)
contains enough minimal logic to load everything it needs for further
initialization from an SD (typically) card. The normal model that has
been established is that cards are provisioned separately and inserted
into a board. Think of these as appliances, kinda. There are ARM
netbooks, but they are rare. We'll get to Anaconda for some of the
bigger stuff later, but for now, that seems less important than ensuring
that we use standard Fedora tools to make the images.

> 6) supported platforms must be fully integrated into building and
>     installation.  If you need a special build procedure to make this happen
>     for kernel, we need to have rel-eng signing off saying they've approved
>     of whatever method that is, and QE signing off that they think it'll
>     result in a something they can claim is tested enough to release as a
>     primary arch.

Fine. I think we got onto a tangent yesterday with the kernel. It's one
part of the overall system. It's an important part, but it's just a
part. What we are proposing is that we target a limited number of ARM
kernel "variants" (subpackages) during a typical build - perhaps even
only versatile - because this allows us to return a built kernel more
quickly than building many variants. I had planned to take this to the
kernel team, but let me just add a few points since it's raised here:

1). There are too many 32-bit ARM kernels. We know this. Work is going
on in Linaro to address that. We will constrain ourselves to a small set
of supportable targets and allow contributors to handle support for more
exotic boards that few people have an interest in, much as anyone could
build a non-PC x86 system and do some kind of non-Fedora for it. A large
amount of "behind the scenes" work is currently ongoing to ensure that
the same 32-bit mistakes do not happen with 64-bit.

2). There is no intention to use anything other than the official kernel
package. The SPEC file can be modified (as it has) to build subpackages
for different ARM targets. My suggestion was that by default we limit
this to a small number, and we retain logic so that it is possible
(through macros, koji flags, whatever) to build a kernel that targets
more ARM platforms in some cases. We will discuss that separately with
the kernel team, as I have said.

3). Kernel build time on our embedded targets is not great compared with
x86. However, the ARM server hardware we will use in PA will have many
times as much cache, memory, etc. and we believe will build the kernel
much more quickly. For workflow, it is my opinion that folks care that
ARM not stall issuing new builds or extracting others from the pipeline.
For example, if you submit a kernel build and it includes x86 and arm
subbuilds, the x86 subbuild won't stall waiting for arm, it will
complete. The only thumb twiddling is waiting for the arm kernel to
complete, which will be a bit longer, but we're also planning to have so
many builder nodes that you won't be blocking for arm builds to begin.
As I said, we'll discuss this with the kernel team.

> 7) it can't be a serious maintenance burdon due to build related issues.
>     We need a couple of groups to sign off that builds are fast enough, not
>     just on a "full distro rebuild" (throughput) level, but also on a
>     "doesn't destroy my workflow due to waiting on it" (latency) level.

Sure. Absolutely is a concern for us, as you can see from my other
comments above about the kernel, for example, but not just that.

Thanks,

Jon.