Re: 2.6.18 Headers - Long

From: Kyle Moffett
Date: Sun Jul 16 2006 - 08:47:03 EST

On Jul 15, 2006, at 17:09:28, Albert Cahalan wrote:
Here we have a full-featured set of atomic ops,

You realize that on a couple architectures it's fundamentally impossible to get atomic ops completely in userspace, right? Some of the mechanisms that various archs use (IIRC including in one or two cases just completely disabling interrupts) don't work anywhere but the kernel.

byte swapping with readable names and a distinction for pointers, nice macros for efficient data structure manipulation...

Both of which may be easily cut and pasted into your GPL programs with little or no effort (Hint: I do this all the time). Those are so stable you don't even have to maintain it! IMHO, what you really want, though, is for GCC to export a library of ASM intrinsics (like memory barriers, atomic ops, etc), that are available on your current architecture. If there is no __gcc_atomic_inc then it wouldn't #define it and you can just go back to pthread_mutex_lock/unlock for protecting an atomic variable. Such a library layer certainly doesn't belong in the kernel, although if GCC got such a library right the kernel might start to use it (although only the most recent GCC would support it so it wouldn't be very useful).

Sure, you'd like all the app developers to [...] use sucky POSIX threads stuff

There is *NO* portable way to get atomic operations or locking in userspace except through libpthread. Atomic operations in the kernel are sometimes _not_ atomic in userspace and the only decent way to do userspace locking is to call into the kernel on contention (or you waste the rest of your timeslice spinning). POSIX thread operations are extremely efficient under Linux, but the kernel shouldn't export the varying underlying operations.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at