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.
Thanks,
Andy
[CC += David]
On 2 June 2015 at 18:36, Andy Lutomirski <[email protected]> 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.
Cheers,
Michael
On Thursday 18 June 2015 09:52:36 Michael Kerrisk wrote:
> [CC += David]
>
> On 2 June 2015 at 18:36, Andy Lutomirski <[email protected]> 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.
Arnd
On Thu, Jun 18, 2015 at 12:58 AM, Arnd Bergmann <[email protected]> wrote:
> On Thursday 18 June 2015 09:52:36 Michael Kerrisk wrote:
>> [CC += David]
>>
>> On 2 June 2015 at 18:36, Andy Lutomirski <[email protected]> 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.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
On Thursday 18 June 2015 11:57:56 Andy Lutomirski wrote:
> On Thu, Jun 18, 2015 at 12:58 AM, Arnd Bergmann <[email protected]> wrote:
> > On Thursday 18 June 2015 09:52:36 Michael Kerrisk wrote:
> >> [CC += David]
> >>
> >> On 2 June 2015 at 18:36, Andy Lutomirski <[email protected]> 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?
Arnd
On Tue, Jun 23, 2015 at 1:44 PM, Arnd Bergmann <[email protected]> wrote:
> On Thursday 18 June 2015 11:57:56 Andy Lutomirski wrote:
>> On Thu, Jun 18, 2015 at 12:58 AM, Arnd Bergmann <[email protected]> wrote:
>> > On Thursday 18 June 2015 09:52:36 Michael Kerrisk wrote:
>> >> [CC += David]
>> >>
>> >> On 2 June 2015 at 18:36, Andy Lutomirski <[email protected]> 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