On Sun, 2012-04-22 at 18:16 -0700, Brendan Conoboy wrote:
As we get closer to having 100% package coverage in F17-ARM we're
running into harder build failures due to the limitations of the chips
we're building for. The problem I've noticed on many of the recent
failures is due to the lack of atomic operations (These didn't arrive
until ARMv6).
What are some examples of these?
How do we want to handle this? I see a few options:
1. Abandon armv5 and move to armv6 where some of the operations we need
are available. This will still support the raspberry pi- what about
kirkwood *plugs?
That would kill the older plugs -- anything below a d2plug.
However: do we care? Much? Going to v6 would let us optimize better for
the Raspi, which will have greater market penetration than the plugs
when existing orders are filled. Otoh, it's a whole 'nuther rebuild.
2. Excludearch armv5tel from the affected packages since they'll
never
work atomically.
3. Accept that these packages simply won't be available to 32 bit Fedora
systems (this is the result of inaction).
4. Pretend operations are atomic when they are not.
5. Create magic patch that implements atomic operations through software.
6. There is the kernel's "user space atomic helper" (kuser_cmpxchg64) at
0xffff0f60, see Documentation/arm/kernel_user_helpers.txt. The kernel
puts an instruction sequence here tuned for the current arch that can be
called by userland to provide an atomic compare/exchange -- if it can be
done natively, the instruction sequence does that, otherwise it does a
syscall (with IRQ protection etc). Would this solve the problems you've
identified?
-Chris