Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933752AbbFWVVP (ORCPT ); Tue, 23 Jun 2015 17:21:15 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:35562 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933635AbbFWVVH (ORCPT ); Tue, 23 Jun 2015 17:21:07 -0400 MIME-Version: 1.0 In-Reply-To: <5721321.xeloEYqQC1@wuerfel> References: <9141492.JqTlmk9dHk@wuerfel> <5721321.xeloEYqQC1@wuerfel> From: Andy Lutomirski Date: Tue, 23 Jun 2015 14:20:46 -0700 Message-ID: Subject: Re: UAPI headers including non-UAPI headers by accident? To: Arnd Bergmann Cc: Michael Kerrisk-manpages , Andy Lutomirski , "linux-kernel@vger.kernel.org" , Linux API , David Woodhouse 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: 2717 Lines: 68 On Tue, Jun 23, 2015 at 1:44 PM, Arnd Bergmann wrote: > On Thursday 18 June 2015 11:57:56 Andy Lutomirski wrote: >> On Thu, Jun 18, 2015 at 12:58 AM, Arnd Bergmann wrote: >> > On Thursday 18 June 2015 09:52:36 Michael Kerrisk wrote: >> >> [CC += David] >> >> >> >> On 2 June 2015 at 18:36, Andy Lutomirski wrote: >> >> > include/uapi/linux/signal.h starts with: >> >> > >> >> > #ifndef _UAPI_LINUX_SIGNAL_H >> >> > #define _UAPI_LINUX_SIGNAL_H >> >> > >> >> > #include >> >> > #include >> >> > >> >> > This causes it to include , which is not the same thing >> >> > as . Changing that will break userspace use of >> >> > this header, though, as the uapi/ won't get removed. >> >> > >> >> > What's the correct fix? This is causing trouble with a UML build for me. >> >> >> >> Perhaps David has some insight, since he architected the original UAPI split. >> > >> > The uapi headers are installed without the uapi prefix. This means >> > that inside of the kernel, we get >> > >> > >> > linux/signal.h >> > -> uapi/linux/signal.h >> > -> asm/signal.h >> > -> uapi/asm/signal.h >> > >> > while in the installed headers we just get >> > >> > linux/signal.h >> > -> asm/signal.h >> > >> > This all looks right to me: user space only sees the exported portions >> > under the traditional names, while the kernel sees both the kernel-side >> > and user-side definitions from the same path. >> > >> >> It seems counterintuitive and error-prone to me that including >> would pull in non-UAPI asm/signal.h declarations >> in the kernel but not when used from userspace. It would make it very >> easy to break the header such that it's only broken in a userspace >> context. >> > > It's an artifact of how the files were originally generated, as the UAPI > headers used to be part of the normal headers, with #ifdef __KERNEL__ around > the parts that are not in include/uapi now. > > For some reason, we now have device drivers including the uapi headers > directly, which was probably done as an accident. Maybe we can just > change them all back to use the normal header file names and add a > checkpatch warning in case someone else tries to use the uapi headers > directly? I don't really mind when a driver includes a UAPI header. IMO the problematic case is when a UAPI header includes a non-UAPI header. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/