bitops.h ifdef __KERNEL__ cleanup.

Please do not do this. At least ncpfs checks for usability of these ops from its configure script, and if they are not available/usable, it reverts to pthread mutex based implementation, which is slower dozen of times. Same applies for atomic_* functions.

I think that you should complain to userspace authors who do not check for bitops existence and not force other to distrbute 8+ versions of bitops.h with their application, together with infrastructure for selecting correct version...

Just my 0.02c.
Petr Vandrovec [email protected]

Both of the above mentioned functions can only be guaranteed to act as per their atomic description if used from kernel space on some architectures.

I've hit this problem many times, and its not going away, because "it works on x86".

In fact, the places I came across when it was causing me problems were places that were just using it as a "oh, someone else has coded a function to set a bit in the kernel, we'll use that instead of coding it in portable C" type thing - the application was single threaded, and was altering a private internal data structure.

Sloppy.

I totally disagree here. We already say "user space should not include kernel headers". Why should bitops.h be any different? Why should atomic.h be any different? They contain architecture specific code, yes, which may not work in user space.

Oh, and thanks for pointing out ncpfs breaks - I hope the authors will fix up their sloppy coding before Davids patch makes it into the kernel. ;)

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html