linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* The UAPI references Kconfig's CONFIG_* macros (variables)
@ 2019-05-11  4:14 Michael Witten
  2019-05-12  6:29 ` Masahiro Yamada
  2019-05-15 21:09 ` Arnd Bergmann
  0 siblings, 2 replies; 3+ messages in thread
From: Michael Witten @ 2019-05-11  4:14 UTC (permalink / raw)
  To: Masahiro Yamada, Michal Marek, David Woodhouse; +Cc: linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4954 bytes --]

The  UAPI  headers  contain  references  to  Kconfig's  `CONFIG_'
macros. Either this is a bug,  or there needs to be some standard
way for users  to provide definitions for these  macros, in order
to complete Linux's user-space API. Consider:

  #!/bin/sh
  cd "${linux_repo}"

  # Careful!
  #git reset --hard HEAD
  #git clean -fdx

  git checkout v5.1
  #zcat /proc/config.gz >.config

  mkdir -p /tmp/uapi/include
  make INSTALL_HDR_PATH=/tmp/uapi headers_install

  printf >/tmp/uapi/raw.c '%s\n%s\n' \
    '#include <linux/raw.h>' \
    'int main() { return MAX_RAW_MINORS; }'

Then:

  $ gcc -c -I/tmp/uapi/include /tmp/uapi/raw.c
  In file included from /tmp/uapi/raw.c:1:0:
  /tmp/uapi/raw.c: In function ‘main’:
  /tmp/uapi/include/linux/raw.h:17:24: error: ‘CONFIG_MAX_RAW_DEVS’ undeclared (first use in this function)
   #define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
                          ^
  /tmp/uapi/raw.c:2:21: note: in expansion of macro ‘MAX_RAW_MINORS’
   int main() { return MAX_RAW_MINORS; }
                       ^~~~~~~~~~~~~~
  /tmp/uapi/include/linux/raw.h:17:24: note: each undeclared identifier is reported only once for each function it appears in
   #define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
                          ^
  /tmp/uapi/raw.c:2:21: note: in expansion of macro ‘MAX_RAW_MINORS’
   int main() { return MAX_RAW_MINORS; }
                       ^~~~~~~~~~~~~~

As you can  see, the UAPI is actually incomplete;  there is not a
valid  definition for  `MAX_RAW_MINORS'.  Indeed,  on my  system,
`CONFIG_MAX_RAW_DEVS'  isn't   ever  defined   anywhere,  because
`CONFIG_RAW_DRIVER' is not set:

  $ git show v5.1:drivers/char/Kconfig | sed -n 467,469p
  config MAX_RAW_DEVS
          int "Maximum number of RAW devices to support (1-65536)"
          depends on RAW_DRIVER
  $ zcat /proc/config.gz | grep RAW_DRIVER
  # CONFIG_RAW_DRIVER is not set

Even if `CONFIG_RAW_DRIVER' were  set, the desired definition for
the  macro  `CONFIG_MAX_RAW_DEVS'  would  only be  found  in  the
following  header (generated  at  built-time),  which is  neither
officially nor likely available to user space:

  "${linux_repo}"/include/generated/autoconf.h

Other  such  references to  `CONFIG_*'  macros  are seen  in  the
following  (some  appear only  in  comments,  but perhaps  that's
conceptually a mistake, too):

  $ (cd /tmp/uapi/include && grep -R . -e \\bCONFIG_)
  ./asm/mman.h:#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
  ./asm/auxvec.h:#if defined(CONFIG_IA32_EMULATION) || !defined(CONFIG_X86_64)
  ./asm/e820.h: * kernel was built: MAX_NUMNODES == (1 << CONFIG_NODES_SHIFT),
  ./asm/e820.h: * unless the CONFIG_X86_PMEM_LEGACY option is set.
  ./asm/e820.h: * if CONFIG_INTEL_TXT is enabled, memory of this type will be
  ./mtd/ubi-user.h: * default kernel value of %CONFIG_MTD_UBI_BEB_LIMIT will be used.
  ./linux/pkt_cls.h:	TCA_FW_INDEV, /*  used by CONFIG_NET_CLS_IND */
  ./linux/pkt_cls.h:	TCA_FW_ACT, /* used by CONFIG_NET_CLS_ACT */
  ./linux/cm4000_cs.h: * member sizes. This leads to CONFIG_COMPAT breakage, since 32bit userspace
  ./linux/eventpoll.h:#ifdef CONFIG_PM_SLEEP
  ./linux/hw_breakpoint.h:#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
  ./linux/bpf.h: * has been built with CONFIG_EFFICIENT_UNALIGNED_ACCESS not set,
  ./linux/bpf.h: * 		the **CONFIG_CGROUP_NET_CLASSID** configuration option set to
  ./linux/bpf.h: * 		**CONFIG_IP_ROUTE_CLASSID** configuration option.
  ./linux/bpf.h: * 		with the **CONFIG_BPF_KPROBE_OVERRIDE** configuration
  ./linux/bpf.h: * 		the CONFIG_FUNCTION_ERROR_INJECTION option. As of this writing,
  ./linux/bpf.h: * 		**CONFIG_XFRM** configuration option.
  ./linux/bpf.h: *		the **CONFIG_BPF_LIRC_MODE2** configuration option set to
  ./linux/bpf.h: *		the **CONFIG_BPF_LIRC_MODE2** configuration option set to
  ./linux/bpf.h: * 		**CONFIG_SOCK_CGROUP_DATA** configuration option.
  ./linux/bpf.h: *		**CONFIG_NET** configuration option.
  ./linux/bpf.h: *		**CONFIG_NET** configuration option.
  ./linux/bpf.h: *		the **CONFIG_BPF_LIRC_MODE2** configuration option set to
  ./linux/raw.h:#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
  ./linux/pktcdvd.h:#if defined(CONFIG_CDROM_PKTCDVD_WCACHE)
  ./linux/flat.h:#ifdef CONFIG_BINFMT_SHARED_FLAT
  ./linux/videodev2.h: * Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
  ./linux/elfcore.h:#ifdef CONFIG_BINFMT_ELF_FDPIC
  ./linux/atmdev.h:#ifdef CONFIG_COMPAT
  ./asm-generic/bitsperlong.h: * both 32 and 64 bit user space must not rely on CONFIG_64BIT
  ./asm-generic/unistd.h:/* mm/, CONFIG_MMU only */
  ./asm-generic/mman-common.h:#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
  ./asm-generic/fcntl.h:#ifndef CONFIG_64BIT

What is the correct way to think about this?

  * Should the UAPI make no reference to build-time configurations?
  * Should the UAPI headers include sanity checks on behalf of the user?
  * Should there be a `/proc/config.h.gz' facility?

Sincerely,
Michael Witten

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: The UAPI references Kconfig's CONFIG_* macros (variables)
  2019-05-11  4:14 The UAPI references Kconfig's CONFIG_* macros (variables) Michael Witten
@ 2019-05-12  6:29 ` Masahiro Yamada
  2019-05-15 21:09 ` Arnd Bergmann
  1 sibling, 0 replies; 3+ messages in thread
From: Masahiro Yamada @ 2019-05-12  6:29 UTC (permalink / raw)
  To: Michael Witten; +Cc: Michal Marek, David Woodhouse, Linux Kernel Mailing List

On Sat, May 11, 2019 at 1:28 PM Michael Witten <mfwitten@gmail.com> wrote:
>
> The  UAPI  headers  contain  references  to  Kconfig's  `CONFIG_'
> macros. Either this is a bug,  or there needs to be some standard
> way for users  to provide definitions for these  macros, in order
> to complete Linux's user-space API. Consider:


In fact, scripts/headers_check.pl has ability to check
CONFIG_ options leaked to user space,
but it has been disabled for a long time.

If you revert the following and run "make headers_check",
you will see lots.

In my understanding, we want to check this,
but it is _still_ too noisy.



commit 7e3fa56141175026136b392fd026d5d07c49720e
Author: Sam Ravnborg <sam@ravnborg.org>
Date:   Fri Jan 30 23:56:42 2009 +0100

    kbuild: drop check for CONFIG_ in headers_check

    The check for references to CONFIG_ symbols in exported headers turned
    out to be too agressive with the current state of affairs.
    After the work of Jaswinder to clean up all relevant cases we are down
    to almost pure noise.

    So lets drop the check for now - we can always add it back later
    should our headers be ready for that.

    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/scripts/headers_check.pl b/scripts/headers_check.pl
index db30fac..56f90a4 100644
--- a/scripts/headers_check.pl
+++ b/scripts/headers_check.pl
@@ -38,7 +38,7 @@ foreach my $file (@files) {
                &check_asm_types();
                &check_sizetypes();
                &check_prototypes();
-               &check_config();
+               # Dropped for now. Too much noise &check_config();
        }
        close FH;
 }









>
>   #!/bin/sh
>   cd "${linux_repo}"
>
>   # Careful!
>   #git reset --hard HEAD
>   #git clean -fdx
>
>   git checkout v5.1
>   #zcat /proc/config.gz >.config
>
>   mkdir -p /tmp/uapi/include
>   make INSTALL_HDR_PATH=/tmp/uapi headers_install
>
>   printf >/tmp/uapi/raw.c '%s\n%s\n' \
>     '#include <linux/raw.h>' \
>     'int main() { return MAX_RAW_MINORS; }'
>
> Then:
>
>   $ gcc -c -I/tmp/uapi/include /tmp/uapi/raw.c
>   In file included from /tmp/uapi/raw.c:1:0:
>   /tmp/uapi/raw.c: In function ‘main’:
>   /tmp/uapi/include/linux/raw.h:17:24: error: ‘CONFIG_MAX_RAW_DEVS’ undeclared (first use in this function)
>    #define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
>                           ^
>   /tmp/uapi/raw.c:2:21: note: in expansion of macro ‘MAX_RAW_MINORS’
>    int main() { return MAX_RAW_MINORS; }
>                        ^~~~~~~~~~~~~~
>   /tmp/uapi/include/linux/raw.h:17:24: note: each undeclared identifier is reported only once for each function it appears in
>    #define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
>                           ^
>   /tmp/uapi/raw.c:2:21: note: in expansion of macro ‘MAX_RAW_MINORS’
>    int main() { return MAX_RAW_MINORS; }
>                        ^~~~~~~~~~~~~~
>
> As you can  see, the UAPI is actually incomplete;  there is not a
> valid  definition for  `MAX_RAW_MINORS'.  Indeed,  on my  system,
> `CONFIG_MAX_RAW_DEVS'  isn't   ever  defined   anywhere,  because
> `CONFIG_RAW_DRIVER' is not set:
>
>   $ git show v5.1:drivers/char/Kconfig | sed -n 467,469p
>   config MAX_RAW_DEVS
>           int "Maximum number of RAW devices to support (1-65536)"
>           depends on RAW_DRIVER
>   $ zcat /proc/config.gz | grep RAW_DRIVER
>   # CONFIG_RAW_DRIVER is not set
>
> Even if `CONFIG_RAW_DRIVER' were  set, the desired definition for
> the  macro  `CONFIG_MAX_RAW_DEVS'  would  only be  found  in  the
> following  header (generated  at  built-time),  which is  neither
> officially nor likely available to user space:
>
>   "${linux_repo}"/include/generated/autoconf.h
>
> Other  such  references to  `CONFIG_*'  macros  are seen  in  the
> following  (some  appear only  in  comments,  but perhaps  that's
> conceptually a mistake, too):
>
>   $ (cd /tmp/uapi/include && grep -R . -e \\bCONFIG_)
>   ./asm/mman.h:#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
>   ./asm/auxvec.h:#if defined(CONFIG_IA32_EMULATION) || !defined(CONFIG_X86_64)
>   ./asm/e820.h: * kernel was built: MAX_NUMNODES == (1 << CONFIG_NODES_SHIFT),
>   ./asm/e820.h: * unless the CONFIG_X86_PMEM_LEGACY option is set.
>   ./asm/e820.h: * if CONFIG_INTEL_TXT is enabled, memory of this type will be
>   ./mtd/ubi-user.h: * default kernel value of %CONFIG_MTD_UBI_BEB_LIMIT will be used.
>   ./linux/pkt_cls.h:    TCA_FW_INDEV, /*  used by CONFIG_NET_CLS_IND */
>   ./linux/pkt_cls.h:    TCA_FW_ACT, /* used by CONFIG_NET_CLS_ACT */
>   ./linux/cm4000_cs.h: * member sizes. This leads to CONFIG_COMPAT breakage, since 32bit userspace
>   ./linux/eventpoll.h:#ifdef CONFIG_PM_SLEEP
>   ./linux/hw_breakpoint.h:#ifdef CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
>   ./linux/bpf.h: * has been built with CONFIG_EFFICIENT_UNALIGNED_ACCESS not set,
>   ./linux/bpf.h: *              the **CONFIG_CGROUP_NET_CLASSID** configuration option set to
>   ./linux/bpf.h: *              **CONFIG_IP_ROUTE_CLASSID** configuration option.
>   ./linux/bpf.h: *              with the **CONFIG_BPF_KPROBE_OVERRIDE** configuration
>   ./linux/bpf.h: *              the CONFIG_FUNCTION_ERROR_INJECTION option. As of this writing,
>   ./linux/bpf.h: *              **CONFIG_XFRM** configuration option.
>   ./linux/bpf.h: *              the **CONFIG_BPF_LIRC_MODE2** configuration option set to
>   ./linux/bpf.h: *              the **CONFIG_BPF_LIRC_MODE2** configuration option set to
>   ./linux/bpf.h: *              **CONFIG_SOCK_CGROUP_DATA** configuration option.
>   ./linux/bpf.h: *              **CONFIG_NET** configuration option.
>   ./linux/bpf.h: *              **CONFIG_NET** configuration option.
>   ./linux/bpf.h: *              the **CONFIG_BPF_LIRC_MODE2** configuration option set to
>   ./linux/raw.h:#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
>   ./linux/pktcdvd.h:#if defined(CONFIG_CDROM_PKTCDVD_WCACHE)
>   ./linux/flat.h:#ifdef CONFIG_BINFMT_SHARED_FLAT
>   ./linux/videodev2.h: * Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
>   ./linux/elfcore.h:#ifdef CONFIG_BINFMT_ELF_FDPIC
>   ./linux/atmdev.h:#ifdef CONFIG_COMPAT
>   ./asm-generic/bitsperlong.h: * both 32 and 64 bit user space must not rely on CONFIG_64BIT
>   ./asm-generic/unistd.h:/* mm/, CONFIG_MMU only */
>   ./asm-generic/mman-common.h:#ifdef CONFIG_MMAP_ALLOW_UNINITIALIZED
>   ./asm-generic/fcntl.h:#ifndef CONFIG_64BIT
>
> What is the correct way to think about this?
>
>   * Should the UAPI make no reference to build-time configurations?
>   * Should the UAPI headers include sanity checks on behalf of the user?
>   * Should there be a `/proc/config.h.gz' facility?
>
> Sincerely,
> Michael Witten



-- 
Best Regards
Masahiro Yamada

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: The UAPI references Kconfig's CONFIG_* macros (variables)
  2019-05-11  4:14 The UAPI references Kconfig's CONFIG_* macros (variables) Michael Witten
  2019-05-12  6:29 ` Masahiro Yamada
@ 2019-05-15 21:09 ` Arnd Bergmann
  1 sibling, 0 replies; 3+ messages in thread
From: Arnd Bergmann @ 2019-05-15 21:09 UTC (permalink / raw)
  To: Michael Witten
  Cc: Masahiro Yamada, Michal Marek, David Woodhouse,
	Linux Kernel Mailing List

On Sat, May 11, 2019 at 6:29 AM Michael Witten <mfwitten@gmail.com> wrote:

>
> What is the correct way to think about this?
>
>   * Should the UAPI make no reference to build-time configurations?

Right, with the exception of uses inside of #ifdef __KERNEL__.

>   * Should the UAPI headers include sanity checks on behalf of the user?
>   * Should there be a `/proc/config.h.gz' facility?

This would not work, since applications don't always run on the systems
they are compiled on, in particular when cross-compiling to another
architecture.

      Arnd

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-05-15 21:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-11  4:14 The UAPI references Kconfig's CONFIG_* macros (variables) Michael Witten
2019-05-12  6:29 ` Masahiro Yamada
2019-05-15 21:09 ` Arnd Bergmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).