ARM as a primary architecture

Tue Mar 20 16:35:33 UTC 2012

On Tue, Mar 20, 2012 at 11:30 AM, Jon Masters <jcm at redhat.com> wrote:
> 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.

What is the tracker bug?  I'd like to take a peek.

>> 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.
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie