On 04/24/2012 05:18 PM, Jon Masters wrote:
On 04/23/2012 04: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.
I wasn't going to reply yet just due to lack of time and because Nico
covered the kernel helper stuff so well in his earlier posts. But just
to add, these kernel helpers have grown a little over time in higher
kernel revisions, but there is a mechanism to discover the revision
available (note: these are not VDSO but if it helps folks understand
them, think of them like that). They are the right way to solve the
atomics problem as best as we can for older devices. I believe the
correct thing to do is to get broken upstream projects to adopt generic
non-reimplemented-of-their-own routines that will transparently use the
kernel helpers if needed.
But is that going to help me? Let's say I'm on an ARMv5 and need to
do a longword operation. I can either use a lightweight spinlock or
take the hit of a system call to do the cmpxchg8 operation. Am I
really better off going into the kernel to do that?
Andrew.