[fedora-arm] ARMv5 and atomic operations

[William Cohen]

On 04/24/2012 07:39 AM, 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?
> 
>> The untested code path is particularly nasty.
> 
> How buggy the following code might be:
> 
> 	fprintf(stderr, "Your kernel is too old, aborting\n")
> 	exit(1);
> 
> ?
> 
> 
> Nicolas

Checking kernel characteristics of the running kernel on a Fedora build system might not be a good idea. The build system might be a chroot jail on an older release (for example fedora 17 chroot on fedora 15).  This was a problem when building the early versions of the papi RPMs. RHEL6 build roots were on RHEL5 machines. Checking the kernel version with a "uname -r" showed a kernel RHEL5 kernel that didn't have the need perf support. However, things were being built for a RHEL6 so this test was misleading.  Is it possible to get this information from kernel-headers rather than probing the running kernel?

-Will