On Tue, Jun 23, 2015 at 1:44 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Thursday 18 June 2015 11:57:56 Andy Lutomirski wrote: >> On Thu, Jun 18, 2015 at 12:58 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> > On Thursday 18 June 2015 09:52:36 Michael Kerrisk wrote: >> >> [CC += David] >> >> >> >> On 2 June 2015 at 18:36, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >> >> > include/uapi/linux/signal.h starts with: >> >> > >> >> > #ifndef _UAPI_LINUX_SIGNAL_H >> >> > #define _UAPI_LINUX_SIGNAL_H >> >> > >> >> > #include <asm/signal.h> >> >> > #include <asm/siginfo.h> >> >> > >> >> > This causes it to include <asm/signal.h>, which is not the same thing >> >> > as <uapi/asm/signal.h>. 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 >> <uapi/linux/signal.h> 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-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
