From: Alan Woodland (awoodland_at_debian_dot_org)
Date: Tue Jan 05 2010 - 09:05:47 PST
2010/1/5 Paul H. Hargrove <PHHargrove_at_lbl_dot_gov>: > Alan, > > � I believe you are mistaken in reading the comments to imply "we > shouldn['t] be using __kernel_cmpxchg on newer kernels anyway". � That > feature became available in 2.6.12 and before that there was no way to > perform an atomic operation from user code w/ pre-ARMv6 hardware. �Since > 2.6.12 this has been the portable way to get an atomic C-A-S. �If there is > specific misleading text in the comment, please show me and I'll fix/clarify > it. Thanks, my confusion was in how a kernel test seemed to be resulting in something getting called directly from userspace, and why it didn't seem to be getting used in the build despite the more recent kernel. The comments are pretty clear now I see how __kuser_cmpxchg is working. > �You ARE correct that CR_KCODE___kuser_cmpxchg is not defined at build time > IF one does separate configuration as the debian packaging apparently does. > �That possibility was not considered when this code was first written, and > is the root cause of your problem. �One should always be in > CR_KCODE___kuser_cmpxchg case for a kernel >= 2.6.12. > > �It was my intention that the swp/swpne code only be used for kernel < > 2.6.12, but probing the kernel for __kuser_cmpxchg was chosen to be a more > reliable probe (a distro could back port the feature to an older base kernel > version). �The fact that you reach this code is because the separate > user/kernel builds have resulted in not probing for > CR_KCODE___kuser_cmpxchg. That makes sense. > If one were to refuse to build for a kernel w/o this feature, then the > �#if defined(CR_KCODE___kuser_cmpxchg) > would/could effectively become equivalent to > �#if 1 > since a userspace built w/o a corresponding kernel module is "harmless". > > �So, I believe the solution to your problem is to force use of the > __kuser_cmpxchg path and require (via packaging magic?) that one have kernel >>= 2.6.12. That seems like the simplest solution to me, a 1 line patch to force that path on arm. I'm not quite sure how to document >= 2.6.12 as a dependency for a library package. Probably the easiest way to get a sensible dependency would be to depend on a more modern libc6 than the automatically generated one. Ubuntu arm people: Shall I just do this and upload to Debian/unstable with LP: #503185 in the changelog? It makes sense for the Debian userspace to be using __kuser_cmpxchg on modern kernels also. (I assume on a kernel prior to 2.6.12 this would build, but give segfault/bus error at run time?) > �I am open to suggestions as to how to deal in general with building the > ARMuser space w/o configuring the kernel module, while still allowing for > the possibility of a pre-2.6.12 kernel. �I am not certain that disallowing > pre-2.6.12 kernels would be popular in the ARM community. For Debian/Ubuntu I think it's safe enough to ignore that problem - Sarge was the last Debian release to see a kernel < 2.6.12, the next Ubuntu release looks set to have at least 2.6.32 as the default kernel. > �In response to your #2: one COULD write an additional #if case to use > ldrex/strex for ARMv6 and ARMv7. �This would gain some efficiency in > exchange for portability to older CPUs, but I lack a platform to test > correctness of such an implementation. I have an ARMv6 on my desk at the moment, but it's not supported by any of the standard Debian/Ubuntu kernel packages to my knowledge and I've never tried anything much more adventurous on it than a Debian chroot. I don't think it's worth the time/effort to do this given that it's better handled by __kuser_cmpxchg anyway. Alan