[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKwvOdnven3n6P6i+WGs_TyWZzH+Cw-RwY8oay0gfnQCfxd=_A@mail.gmail.com>
Date: Thu, 13 Dec 2018 14:25:17 -0800
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: liuxiaozhou@...edance.com, Greg KH <gregkh@...uxfoundation.org>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
paul.burton@...s.com, Arnd Bergmann <arnd@...db.de>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2] Compiler Attributes: don't pollute userspace with
macro definitions
>> compiling error
>> showing "unknown type name ‘__gnu_inline’" will pop up, if userspace
>> somehow includes <linux/compiler.h>.
Oops.
> If not, I can pick it up in compiler-attributes tree linux-next.
That's probably the best, unless we'd like this fix in mainline ASAP?
Moving the __KERNEL__ guard should not affect the kernel, only what
userspace sees. __gnu_inline only affects which
implementation/definition you get, so even if userspace doesn't know
what the kernel's inline is redefined to, it should not matter as
userspace should only ever care about the function signature, which
does not change between our definitions of inline.
Acked-by: Nick Desaulniers <ndesaulniers@...gle.com>
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists