On Fri, Dec 14, 2018 at 2:02 AM Miguel Ojeda
wrote:
>
> On Thu, Dec 13, 2018 at 11:25 PM Nick Desaulniers
> wrote:
> >
> > 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
Hi Miguel,
On Thu, Dec 13, 2018 at 10:59:10PM +0100, Miguel Ojeda wrote:
> I wonder if we can/should simply move them into the __KERNEL__ &&
> !__ASSEMBLY__ block that is above, instead. It would be simpler to
> read, and there aren't apparently dependencies to those outside it
> that go after
On Thu, Dec 13, 2018 at 11:25 PM Nick Desaulniers
wrote:
>
> 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
>> compiling error
>> showing "unknown type name ‘__gnu_inline’" will pop up, if userspace
>> somehow includes .
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
On Thu, Dec 13, 2018 at 10:59 PM Miguel Ojeda
wrote:
>
> What do you think?
[Cc'ing Nick et. al. as well.]
Cheers,
Miguel
Hi Xiaozhou,
Couple of comments.
On Sun, Dec 9, 2018 at 4:27 AM Xiaozhou Liu wrote:
>
> v2: update commit message.
This line should go below the "---", since it shouldn't be part of the
commit message.
> +#ifdef __KERNEL__
> +
> #ifdef CONFIG_ENABLE_MUST_CHECK
> #define __must_check
Macros 'inline' and '__gnu_inline' used to be defined within __KERNEL__.
Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
exclusive") had them exposed to userspace (unintentionally).
Then commit a3f8a30f3f00 ("Compiler Attributes: use feature checks instead
of version
7 matches
Mail list logo
