Re: bitops.h ifdef __KERNEL__ cleanup.

[Russell King <rmk@arm.linux.org.uk>]

On Thu, Jul 19, 2001 at 12:54:43PM +0000, Petr Vandrovec wrote:
> 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.

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 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...

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html