[fedora-arm] ARMv5 and atomic operations

[Gordan Bobic]

William Cohen wrote:
> 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?

I am sure I remember having been bitten by this when rebuilding RHEL6 
src.rpms on F12/F13 builders but for the life of me I cannot recall 
which packages were involved. IMO a builder that isn't the same version 
as the distro being built should only ever be used for a bootstrapping 
build - otherwise all sorts of anomalies creep in. Having said that, it 
is a good idea to hunt down the sources of such anomalies, so from that 
point of view, a kernel/distro mismatch on the builders is a good thing 
from the point of view of thorough testing.

Gordan