Re: ARM Primary FESCO discussion results, round 1
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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=673691Otherwise not paying attention to alignment in something like e2fsprogs could plausibly trash the file system:
https://bugzilla.redhat.com/show_bug.cgi?id=680090Even 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 :-PI 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm