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