why is there still so much __KERNEL__ testing in include/uapi/?

why is there still so much __KERNEL__ testing in include/uapi/?

[Robert P. J. Day]

  continuing down this road of exporting kernel headers, under
include/uapi/ (and mostly further under linux/), there's still a *ton*
of testing of the __KERNEL__ preprocessor check.

  now, i realize that when one does "make headers_install", all those
files are run through "unifdef" to sanitize almost all of that kernel
content, so it's not like it hurts, but is there any reason so much of
it is still there? wouldn't it be tidier to get rid of it?

  or is there some rationale for leaving it there?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

why is there still so much __KERNEL__ testing in include/uapi/?

[Greg KH]

On Fri, May 27, 2016 at 12:08:09PM -0400, Robert P. J. Day wrote:
> 
>   continuing down this road of exporting kernel headers, under
> include/uapi/ (and mostly further under linux/), there's still a *ton*
> of testing of the __KERNEL__ preprocessor check.
> 
>   now, i realize that when one does "make headers_install", all those
> files are run through "unifdef" to sanitize almost all of that kernel
> content, so it's not like it hurts, but is there any reason so much of
> it is still there? wouldn't it be tidier to get rid of it?

No, because not all of the information in those .h files should be
exported to userspace.  You could either split the files all up into two
different ones, or just live with the existing infrastructure we have.
We chose the easy one :)

greg k-h

why is there still so much __KERNEL__ testing in include/uapi/?

[Robert P. J. Day]

On Fri, 27 May 2016, Greg KH wrote:

> On Fri, May 27, 2016 at 12:08:09PM -0400, Robert P. J. Day wrote:
> >
> >   continuing down this road of exporting kernel headers, under
> > include/uapi/ (and mostly further under linux/), there's still a *ton*
> > of testing of the __KERNEL__ preprocessor check.
> >
> >   now, i realize that when one does "make headers_install", all those
> > files are run through "unifdef" to sanitize almost all of that kernel
> > content, so it's not like it hurts, but is there any reason so much of
> > it is still there? wouldn't it be tidier to get rid of it?
>
> No, because not all of the information in those .h files should be
> exported to userspace.  You could either split the files all up into
> two different ones, or just live with the existing infrastructure we
> have. We chose the easy one :)

  ok, i think i see *part* of my misunderstanding so let me back up a
bit ... are any of the header files *directly* under include/linux
processed for exporting? because there is no file
include/linux/Kbuild, which i assume needs to exist for that to
happen.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

why is there still so much __KERNEL__ testing in include/uapi/?

[Robert P. J. Day]

On Fri, 27 May 2016, Greg KH wrote:

> On Fri, May 27, 2016 at 12:08:09PM -0400, Robert P. J. Day wrote:
> >
> >   continuing down this road of exporting kernel headers, under
> > include/uapi/ (and mostly further under linux/), there's still a
> > *ton* of testing of the __KERNEL__ preprocessor check.
> >
> >   now, i realize that when one does "make headers_install", all
> > those files are run through "unifdef" to sanitize almost all of
> > that kernel content, so it's not like it hurts, but is there any
> > reason so much of it is still there? wouldn't it be tidier to get
> > rid of it?
>
> No, because not all of the information in those .h files should be
> exported to userspace.  You could either split the files all up into
> two different ones, or just live with the existing infrastructure we
> have. We chose the easy one :)

  ok, after further perusal, i can see the misunderstandings i had,
mostly because i'd never read the rationale and design for UAPI
closely enough.

  originally, i thought the whole point of the uapi/ directories was
to factor out, as thoroughly as possible, user space-only header file
content, and certainly there are header files where there is a
beautiful, clean break between kernel space stuff and user space
stuff, so splitting such a file into two parts is easy.

  so my first mistake was thinking that there should be very little
__KERNEL__ checking in the uapi/ directories. there are, of course,
cases where it's just not feasible to do a perfect partitioning, like
in cases where a single structure definition might contain:

  #ifdef __KERNEL__
    some member
  #else
    some other member
  #endif

so, sure, that sort of thing would be retained in a uapi/ header file,
and would be finally sanitized as part of the headers install process.

  what i'm massively embarrassed to admit is that i didn't know the
uapi/ directories are part of the normal kernel header file search
path:

  # Use USERINCLUDE when you must reference the UAPI directories only.
  USERINCLUDE    := \
                -I$(srctree)/arch/$(hdr-arch)/include/uapi \
                -Iarch/$(hdr-arch)/include/generated/uapi \
                -I$(srctree)/include/uapi \
                -Iinclude/generated/uapi \
                -include $(srctree)/include/linux/kconfig.h

  # Use LINUXINCLUDE when you must reference the include/ directory.
  # Needed to be compatible with the O= option
  LINUXINCLUDE    := \
                -I$(srctree)/arch/$(hdr-arch)/include \
                -Iarch/$(hdr-arch)/include/generated/uapi \
                -Iarch/$(hdr-arch)/include/generated \
                $(if $(KBUILD_SRC), -I$(srctree)/include) \
                -Iinclude \
                $(USERINCLUDE)

which means that rather than trying to refactor a header file into
kernel and user space parts, you can just say, "ah, the heck with it,"
and move it into uapi/, where it will be the *only* version of that
header file in the kernel source tree, suitable for use in both kernel
and user space.  case in point:

  $ find . -name virtio_blk.h
  ./include/uapi/linux/virtio_blk.h
  $

and in cases like that, sure, there could be all sorts of __KERNEL__
checking going on to distinguish kernel space content from user space
content.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================