[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060716124824.GA11883@flint.arm.linux.org.uk>
Date: Sun, 16 Jul 2006 13:48:25 +0100
From: Russell King <rmk+lkml@....linux.org.uk>
To: Kyle Moffett <mrmacman_g4@....com>
Cc: Albert Cahalan <acahalan@...il.com>, dwmw2@...radead.org,
arjan@...radead.org, maillist@...55.com, ralf@...ux-mips.org,
linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: 2.6.18 Headers - Long
On Sun, Jul 16, 2006 at 08:34:53AM -0400, Kyle Moffett wrote:
> There is *NO* portable way to get atomic operations or locking in
> userspace except through libpthread.
And as one of the maintainers of an architecture where this is true
(neither atomic.h nor bitops.h will work in userspace atomically) I
whole heartedly agree that the kernel's atomic operations must not
be exported to userspace via header files.
Anyone who thinks they will or should do is just kidding themselves.
The final point to add to this is that folk might be lucky, and the
kernel's atomic ops might _appear_ to work without raising any faults,
but that does _not_ mean that they are necessarily atomic in their
operation. For example:
unsigned long *a;
a[bit >> 5] |= 1 << (bit & 31);
and
set_bit(bit, &a);
are 100% equivalent in userspace if you use the kernel's asm-arm/bitops.h.
Neither will be atomic. More importantly, _neither_ could be made to be
atomic.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists