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

[Gordan Bobic]

On 03/20/2012 08:00 PM, Brendan Conoboy wrote:
> On 03/20/2012 02:48 AM, Gordan Bobic wrote:
>> Are alignment problems not considered bugs? It's not just that this will
>> break code on ARM < v7 and IIRC SPARC, but alignment issues also cause
>> cache line straddling which has a performance impact.
>
> I took this question to be a case of
> knowing-just-enough-about-ARM-to-be-harmful. It's really a non-issue,
> particularly since later ARM chips don't have the problem.

I disagree. ARMv5 is going to be around for a while yet, and the fix-up 
in software at least needs to be implemented either by default or set as 
the very first thing in rc.sysinit:

https://bugzilla.redhat.com/show_bug.cgi?id=673691

Otherwise not paying attention to alignment in something like e2fsprogs 
could plausibly trash the file system:

https://bugzilla.redhat.com/show_bug.cgi?id=680090

Even if sloppy programming is not an issue on later ARMs, IMO the 
alignment issues should be treated as bugs at least until ARMv5 support 
is completely dropped.

>> Is there any actual reason why Anaconda cannot be used? What is to stop
>> booting a suitable installation kernel for the target platform and
>> having that fetch/mount an installation rootfs that takes over, same as
>> it does in x86? Granted the amount of RAM is an issue, but that's just a
>> case of dieting the installer back to a saner size (de-lobotomizing the
>> text mode installer back to how it was before F11, for example).
>
> Anaconda isn't *quite* ready to go yet. And you don't actually gain much
> by using Anaconda for many devices- you still have to write an image to
> a removal storage device. Which you then run boot... and it writes a new
> image to a storage device. You've just made more work for yourself when
> you could have installed a working image directly.

In that case you might as well use the same installation procedure on 
x86, too - there's no reason not to.

> On the server side, PXE abilities mean there's more to be said about
> Anaconda support. The only issue is, they don't exist yet :-P
>
>> I found that if the kernel has support for the right SoC, it is simply a
>> case of adding a suitable SoC merge config file and plumbing it in for
>> the build based on a build flag. I have somewhere a
>> 2.6.32-220.<something> kernel src.rpm that builds for both x86 and
>> Marvell Kirkwood, and it was reasonably straightforward to achieve (even
>> if it did require fixing a few bugs that were introduced by upstream
>> vendor patches that didn't manifest on the primary arch).
>
> Yes, using one kernel source rpm is working fine for us. It's the long
> build time which needs to be overcome.

distcc helps.

Gordan