Thread (85 messages) 85 messages, 12 authors, 2016-01-11

Re: [PATCH v2 17/32] arm: define __smp_xxx

From: Peter Zijlstra <peterz@infradead.org>
Date: 2016-01-04 13:54:42
Also in: linux-arch, linux-arm-kernel, linux-mips, linux-s390, linux-sh, linux-um, lkml, sparclinux, virtualization

On Mon, Jan 04, 2016 at 02:36:58PM +0100, Peter Zijlstra wrote:
On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote:
quoted
On Sat, Jan 02, 2016 at 11:24:38AM +0000, Russell King - ARM Linux wrote:
quoted
quoted
My only concern is that it gives people an additional handle onto a
"new" set of barriers - just because they're prefixed with __*
unfortunately doesn't stop anyone from using it (been there with
other arch stuff before.)

I wonder whether we should consider making the smp memory barriers
inline functions, so these __smp_xxx() variants can be undef'd
afterwards, thereby preventing drivers getting their hands on these
new macros?
That'd be tricky to do cleanly since asm-generic depends on
ifndef to add generic variants where needed.

But it would be possible to add a checkpatch test for this.
Wasn't the whole purpose of these things for 'drivers' (namely
virtio/xen hypervisor interaction) to use these?
Ah, I see, you add virt_*mb() stuff later on for that use case.

So, assuming everybody does include asm-generic/barrier.h, you could
simply #undef the __smp version at the end of that, once we've generated
all the regular primitives from it, no?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help