lkml.org 
[lkml]   [2006]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.6.18 Headers - Long
Date
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.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-07-16 14:39    [W:0.100 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site