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:

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

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.

arm mailing list

[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux