Re: [PATCH] Compiler Attributes: move kernel-only attributes into __KERNEL__

[Miguel Ojeda]

On Thu, Nov 29, 2018 at 3:16 AM Xiaozhou Liu <lxz1983@xxxxxxxxx> wrote:
>
> On Wed, Nov 28, 2018 at 06:35:18PM +0100, Miguel Ojeda wrote:
>
> By `these' I mean inline and the like, to be clear.

Ah, that makes more sense! Sorry.

> > That is not exactly correct -- a3f8a30f3f00 moved some attributes to
> > another file, moving them into __KERNEL__ (in particular,__gnu_inline
> > is).
>
> Yes, that is what a3f8a30f3f00 did. Sorry.
> Turns out the commits in question are 815f0ddb346c and a3f8a30f3f00.

No problem! It was a bit confusing indeed.

> Yes and no. Let's recall the whole story.
>
> Before 815f0ddb346c("include/linux/compiler*.h: make compiler-*.h mutually exclusive"),
> __gnu_inline and inline were both *in* __KERNEL__ as the were in
> <linux/compiler-gcc.h>, which was entirely put to __KERNEL__ in
> <linux/compiler_types.h>. Everything was fine.
>
> Then 815f0ddb346c moved inline and __gnu_inline *out* of __KERNEL__
> and put them in <linux/compiler_types.h> so userspace could see them
> both. Not sure if it's intended behavior, but everything looked fine.
>
> Then a3f8a30f3f00 moved __gnu_inline back into __KERNEL__ and left
> inline behind. Since inline depends on __gnu_inline, error showing
> "unknown type name â__gnu_inlineâ" pops up.

Exactly, thanks a lot for clarifying it up (we should put this in the
commit message, I would say). That also answers my question: it is
clear everything should be back into __KERNEL__. The only worry is
that the v4.19 release contained 815f0ddb346c, so it has them exposed,
so someone could have started relying on them. Or, more likely, the
exposed macros could break some source code out there. Hm... Should a
"fix" be backported?

Cheers,
Miguel