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