On Fri, 24 Aug 2007, Satyam Sharma wrote: > But if people do seem to have a mixed / confused notion of atomicity > and barriers, and if there's consensus, then as I'd said earlier, I > have no issues in going with the consensus (eg. having API variants). > Linus would be more difficult to convince, however, I suspect :-) The confusion may be the result of us having barrier semantics in atomic_read. If we take that out then we may avoid future confusions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Chris Snook <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Heiko Carstens <[email protected]>
- [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init_deassert()
- From: Satyam Sharma <[email protected]>
- Re: [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init_deassert()
- From: Denys Vlasenko <[email protected]>
- Re: [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init_deassert()
- From: Satyam Sharma <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Prev by Date: Re: [PATCH] Fix find_next_best_node (Re: [BUG] 2.6.23-rc3-mm1 Kernel panic - not syncing: DMA: Memory would be corrupted)
- Next by Date: [PATCH 1/2] NBD: set uninitialized devices to size 0
- Previous by thread: Re: [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init_deassert()
- Next by thread: Re: [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init_deassert()
- Index(es):
 |