On 29/08/2019 18.05, Linus Torvalds wrote: > On Thu, Aug 29, 2019 at 1:32 AM Rasmus Villemoes > <[email protected]> wrote: >> >> But since we #define the identifier inline to attach some attributes, >> we have to use the alternate spelling __inline__ of that >> keyword. Unfortunately, we also currently #define that one (to >> inline), so we first have to get rid of all (mis)uses of >> __inline__. Hence the huge diffstat. > > Ugh. Not pretty, but I guess we're stuck with it. > > However, it worries me a bit that you excluide the UAPI headers where > we still use "__inline__", and now the semantics of that will change > for the kernel (for some odd gcc versions).
Yeah, as I wrote I was aware of that, but didn't have any good ideas, so I was fishing. Doing #ifdef __KERNEL__ #define __uapi_inline inline #else #define __uapi_inline __inline__ #endif was one of the bad ideas... > I suspect we should just bite the bullet and you should do it to the > uapi headers too. We already use "inline" in a lot of them, so it's > not the case that we're using __inline__ because of some namespace > issue, as far as I can tell. > > One option might be to just use "__inline" for the asm_inline thing. > We have way fewer of those. That would make the noise much less for > this patch series. Ah, interesting. I didn't know that was also a compiler provided alias. It seems to be entirely undocumented - https://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html just mentions the __inline__ (and __asm__) spellings. But it's clear as day in the gcc sources { "__inline", RID_INLINE, 0 }, { "__inline__", RID_INLINE, 0 }, and has been that way since forever, AFAICT. So yes, let's just start by getting rid of the __inline define and fix the staging (+acpi,zstd) users, to allow asm_inline to progress. I'll respin. Rasmus
