Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757398AbcC2SL6 (ORCPT ); Tue, 29 Mar 2016 14:11:58 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:36742 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752059AbcC2SL4 (ORCPT ); Tue, 29 Mar 2016 14:11:56 -0400 MIME-Version: 1.0 In-Reply-To: <56FAC3E6.5090007@redhat.com> References: <56FAC3E6.5090007@redhat.com> Date: Tue, 29 Mar 2016 14:11:35 -0400 X-Google-Sender-Auth: AL-dV9bUxeSsUgt6SadW7AeaMtY Message-ID: Subject: Re: Commit bc27fb68aaad4 breaks qemu build From: Josh Boyer To: Denys Vlasenko Cc: Ingo Molnar , Andrew Morton , Linus Torvalds , "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1435 Lines: 38 Adding lkml, which I forgot to do in my original email. On Tue, Mar 29, 2016 at 2:05 PM, Denys Vlasenko wrote: > On 03/29/2016 02:41 PM, Josh Boyer wrote: >> Hello, >> >> We've had a report[1] that the changes to include/uapi/linux/swab.h >> breaks the build for qemu. This appears to be because the >> __always_inline attribute is added to some of the definitions in a >> uapi header, but that attribute itself is defined in >> include/linux/compiler.h (compiler-gcc.h to be specific). The >> compiler.h header isn't exported to userspace via the uapi mechanism >> which means __always_inline isn't defined. >> >> There are likely two options here. The first is to revert the change, >> but that breaks busybox or something. The second is to use the >> definition of __always_inline itself in the uapi headers, specifying >> "inline __attribute__((always_inline)) explicitly. There might be >> other solutions, but at the moment things seem broken. >> >> Opinions? > > I propose moving this block in compiler.h: > > #ifndef __always_inline > #define __always_inline inline > #endif > > #endif /* __KERNEL__ */ > > to sit outside of __KERNEL__ guard. Sending a patch shortly. I'm not sure that will work. As I said, include/linux/compiler.h (and all variants of that) are not exported by uapi. So whatever you do in those files won't be reflected on anything installed in /usr/include/linux afaik. josh