Messages in this thread | | | From | Nick Desaulniers <> | Date | Tue, 4 Dec 2018 13:21:25 -0800 | Subject | Re: [PATCH] Compiler Attributes: move kernel-only attributes into __KERNEL__ |
| |
On Wed, Nov 28, 2018 at 9:35 AM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > Hi Xiaozhou, > > On Wed, Nov 28, 2018 at 3:09 PM Xiaozhou Liu <liuxiaozhou@bytedance.com> wrote: > > > > Attributes such as `__gnu_inline' are meant to be used within the > > kernel. When userspace somehow includes <linux/compiler.h> > > (eg. tools/bpf), compilation errors would be shown: > > > > "error: unknown type name ‘__gnu_inline’" > > > > So just move these things into __KERNEL__ and the behavior is kept > > as before. > > That is not exactly correct -- a3f8a30f3f00 moved some attributes to > another file, moving them into __KERNEL__ (in particular,__gnu_inline > is). > > The problem is, instead, that __gnu_inline is not anymore defined > outside __KERNEL__, but something else that uses it is (the inline > macro definition, if I had to guess). > > If your problem is fixed by putting __gnu_inline into __KERNEL__ > again, it means we can simply move the inline definition inside > __KERNEL__ too. That way, we don't pollute userspace users with macro > definitions. > > Having said that, does someone know whether userspace should have > access to those attributes (or rather, other code that uses in turn > those attributes)?
This is tricky territory; the kernel is redefining `inline` in headers in order to get __attribute__((gnu_inline)) semantics. If non kernel users include those headers, the kernel may be redefining the semantics of `inline` for those programs (unexpectedly). Admittedly, gnu_inline kind of an edge case so most users might not notice, but that may be an argument for `-f gnu_inline` rather than redefining `inline` in a header.
> > Cheers, > Miguel
-- Thanks, ~Nick Desaulniers
| |