[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7436.1580466021@warthog.procyon.org.uk>
Date: Fri, 31 Jan 2020 10:20:21 +0000
From: David Howells <dhowells@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: dhowells@...hat.com, Will Deacon <will@...nel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Android Kernel Team <kernel-team@...roid.com>,
Michael Ellerman <mpe@...erman.id.au>,
Peter Zijlstra <peterz@...radead.org>,
Segher Boessenkool <segher@...nel.crashing.org>,
Christian Borntraeger <borntraeger@...ibm.com>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
Arnd Bergmann <arnd@...db.de>,
Peter Oberparleiter <oberpar@...ux.ibm.com>,
Masahiro Yamada <masahiroy@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 00/10] Rework READ_ONCE() to improve codegen
Of course, if you're feeling adventurous and willing to at least entertain the
mere speculation of switching the kernel source to C++, we could then use
inline template functions:
template <typename T>
static inline T __READ_ONCE(T &var)
{
T val = *(const volatile T *)&var;
return val;
}
template <typename T>
static inline T READ_ONCE(T &var)
{
T val;
compiletime_assert_rwonce_type(var);
val = __READ_ONCE(var);
smp_read_barrier_depends();
return val;
}
Of course, that would mean using C++...
David
Powered by blists - more mailing lists