On 04/24/2012 04:49 PM, Nicolas Pitre wrote: > On Tue, 24 Apr 2012, Andrew Haley wrote: > >> On 04/24/2012 12:39 PM, Nicolas Pitre wrote: >>> On Tue, 24 Apr 2012, Andrew Haley wrote: >>> >>>> On 04/23/2012 09:31 PM, Nicolas Pitre wrote: >>>>> On Mon, 23 Apr 2012, Andrew Haley wrote: >>>>> >>>>>> On 04/23/2012 06:36 PM, Thomas Meyer wrote: >>>>>>> I'm running the Ubuntun 2.6.38 Tegra2 kernel (because of their fbdev >>>>>>> support) on top of Fedora 17 armv5el on an Toshiba AC100 Laptop. The >>>>>>> rsyslog package crashed everytime because of the missing kernel support >>>>>>> of cmpxchg64. So when relying on the kernel helpers make sure that the >>>>>>> resp. kernel support exists. >>>>>> >>>>>> Indeed. I had to write a workaround in IcedTea (i.e. java) on ARM for >>>>>> just this reason. If you can't depend on a kernel helper being there I >>>>>> can't see it's of any use. >>>>> >>>>> Kernel helpers don't disappear with time. You therefore can probe for >>>>> their availability (see the documentation) in case the kernel support >>>>> could be backported, or just refuse to run if the kernel version isn't >>>>> recent enough. This is not much different from relying on a new >>>>> syscall. >>>> >>>> Indeed it is. What would I gain from adding such a test? All I can >>>> see is extra complication, untested code paths, and larger programs. >>> >>> What alternative do you have, other than not using any atomic >>> operations? >> >> What I've done already: I have my own routines. > > You may get some atomicity with the SWP instruction, but that is not > sufficient to implement atomic increments and the like. > > You may use the SWP to implement some locking and perform the "atomic" > operations under the lock protection, but that doesn't work if atomic > operations are also performed in signal handlers, and that scales badly > if concurency is high. > > So that really depends what your atomic needs are. Implementing the > latest library standards without any kernel help on ARMv5 or earlier is > simply impossible. But custom code can get away with less. Oh I see what you mean now. I'm inside the Java VM, so I can fall back to locking if I'm on ARMv5; ldrexd is an optimization for doing long-word updates rather than needed for correctness. So, if I'm on v7 I have to have my own cmpxchg64 routines for older kernels. I have to fall back to locks on older CPUs, because I still want to work on old kernels too. I can't see any circumstances where the kernel helper will be of any use. Andrew. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
