Skip to content
Snippets Groups Projects
  1. Jun 15, 2019
    • Masahiro Yamada's avatar
      kbuild: move hdr-inst shorthand to top Makefile · a5bae54c
      Masahiro Yamada authored
      
      Now that hdr-inst is used only in the top Makefile, move it there
      from scripts/Kbuild.include.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      a5bae54c
    • Masahiro Yamada's avatar
      kbuild: re-implement Makefile.headersinst without recursion · d5470d14
      Masahiro Yamada authored
      
      Since commit fcc8487d ("uapi: export all headers under uapi
      directories"), the headers in uapi directories are all exported by
      default although exceptional cases are still allowed by the syntax
      'no-export-headers'.
      
      The traditional directory descending has been kept (in a somewhat
      hacky way), but it is actually unneeded.
      
      Get rid of it to simplify the code.
      
      Also, handle files one by one instead of the previous per-directory
      processing. This will emit much more log, but I like it.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      d5470d14
    • Masahiro Yamada's avatar
      kbuild: add 'headers' target to build up uapi headers in usr/include · 59b2bd05
      Masahiro Yamada authored
      
      In Linux build system, build targets and installation targets are
      separated.
      
      Examples are:
      
       - 'make vmlinux' -> 'make install'
       - 'make modules' -> 'make modules_install'
       - 'make dtbs'    -> 'make dtbs_install'
       - 'make vdso'    -> 'make vdso_install'
      
      The intention is to run the build targets under the normal privilege,
      then the installation targets under the root privilege since we need
      the write permission to the system directories.
      
      We have 'make headers_install' but the corresponding 'make headers'
      stage does not exist. The purpose of headers_install is to provide
      the kernel interface to C library. So, nobody would try to install
      headers to /usr/include directly.
      
      If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
      some build artifacts in the kernel tree would be owned by root because
      some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
      targets.
      
      Anyway, I believe it makes sense to split the header installation into
      two stages.
      
       [1] 'make headers'
          Process headers in uapi directories by scripts/headers_install.sh
          and copy them to usr/include
      
       [2] 'make headers_install'
          Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include
      
      For the backward compatibility, 'headers_install' depends on 'headers'.
      
      Some samples expect uapi headers in usr/include. So, the 'headers'
      target is useful to build up them in the fixed location usr/include
      irrespective of INSTALL_HDR_PATH.
      
      Another benefit is to stop polluting the final destination with the
      time-stamp files '.install' and '.check'. Maybe you can see them in
      your toolchains.
      
      Lastly, my main motivation is to prepare for compile-testing uapi
      headers. To build something, we have to save an object and .*.cmd
      somewhere. The usr/include/ will be the work directory for that.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      59b2bd05
    • Masahiro Yamada's avatar
      kbuild: remove build_unifdef target in scripts/Makefile · 2b8481be
      Masahiro Yamada authored
      
      Since commit 2aedcd09 ("kbuild: suppress annoying "... is up to date."
      message"), if_changed and friends nicely suppress "is up to date" messages.
      
      We do not need per-Makefile tricks.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      2b8481be
    • Masahiro Yamada's avatar
      kbuild: remove headers_{install,check}_all · f3c8d4c7
      Masahiro Yamada authored
      
      headers_install_all does not make much sense any more because different
      architectures export different set of uapi/linux/ headers. As you see
      in include/uapi/linux/Kbuild, the installation of a.out.h, kvm.h, and
      kvm_para.h is arch-dependent. So, headers_install_all repeats the
      installation/removal of them.
      
      If somebody really thinks it is useful to do headers_install for all
      architectures, it would be possible by small shell-scripting, but
      the top Makefile does not have to provide entry targets just for that
      purpose.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      f3c8d4c7
  2. Jun 09, 2019
    • Mathieu Malaterre's avatar
      kbuild: Remove -Waggregate-return from scripts/Makefile.extrawarn · 869ee58b
      Mathieu Malaterre authored
      
      It makes little sense to pass -Waggregate-return these days since large
      part of the linux kernel rely on returning struct(s). For instance:
      
        ../include/linux/timekeeping.h: In function 'show_uptime':
        ../include/linux/ktime.h:91:34: error: function call has aggregate value [-Werror=aggregate-return]
         #define ktime_to_timespec64(kt)  ns_to_timespec64((kt))
                                          ^~~~~~~~~~~~~~~~~~~~~~
        ../include/linux/timekeeping.h:166:8: note: in expansion of macro 'ktime_to_timespec64'
          *ts = ktime_to_timespec64(ktime_get_coarse_boottime());
      
      Remove this warning from W=2 completely.
      
      Signed-off-by: default avatarMathieu Malaterre <malat@debian.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      869ee58b
  3. Jun 07, 2019
    • Masahiro Yamada's avatar
      kbuild: use more portable 'command -v' for cc-cross-prefix · 913ab978
      Masahiro Yamada authored
      To print the pathname that will be used by shell in the current
      environment, 'command -v' is a standardized way. [1]
      
      'which' is also often used in scripts, but it is less portable.
      
      When I worked on commit bd55f96f ("kbuild: refactor cc-cross-prefix
      implementation"), I was eager to use 'command -v' but it did not work.
      (The reason is explained below.)
      
      I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
      thought it was no longer needed. Sorry, I was wrong.
      
      It works well on my Ubuntu machine, but Alexey Brodkin reports noisy
      warnings on CentOS7 when 'which' fails to find the given command in
      the PATH environment.
      
        $ which foo
        which: no foo in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
      
      Given that behavior of 'which' depends on system (and it may not be
      installed by default), I want to try 'command -v' once again.
      
      The specification [1] clearly describes the behavior of 'command -v'
      when the given command is not found:
      
        Otherwise, no output shall be written and the exit status shall reflect
        that the name was not found.
      
      However, we need a little magic to use 'command -v' from Make.
      
      $(shell ...) passes the argument to a subshell for execution, and
      returns the standard output of the command.
      
      Here is a trick. GNU Make may optimize this by executing the command
      directly instead of forking a subshell, if no shell special characters
      are found in the command and omitting the subshell will not change the
      behavior.
      
      In this case, no shell special character is used. So, Make will try
      to run it directly. However, 'command' is a shell-builtin command,
      then Make would fail to find it in the PATH environment:
      
        $ make ARCH=m68k defconfig
        make: command: Command not found
        make: command: Command not found
        make: command: Command not found
      
      In fact, Make has a table of shell-builtin commands because it must
      ask the shell to execute them.
      
      Until recently, 'command' was missing in the table.
      
      This issue was fixed by the following commit:
      
      | commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
      | Author: Paul Smith <psmith@gnu.org>
      | Date:   Sun Nov 12 18:10:28 2017 -0500
      |
      |     * job.c: Add "command" as a known shell built-in.
      |
      |     This is not a POSIX shell built-in but it's common in UNIX shells.
      |     Reported by Nick Bowler <nbowler@draconx.ca>.
      
      Because the latest release is GNU Make 4.2.1 in 2016, this commit is
      not included in any released versions. (But some distributions may
      have back-ported it.)
      
      We need to trick Make to spawn a subshell. There are various ways to
      do so:
      
       1) Use a shell special character '~' as dummy
      
          $(shell : ~; command -v $(c)gcc)
      
       2) Use a variable reference that always expands to the empty string
          (suggested by David Laight)
      
          $(shell command$${x:+} -v $(c)gcc)
      
       3) Use redirect
      
          $(shell command -v $(c)gcc 2>/dev/null)
      
      I chose 3) to not confuse people. The stderr would not be polluted
      anyway, but it will provide extra safety, and is easy to understand.
      
      Tested on Make 3.81, 3.82, 4.0, 4.1, 4.2, 4.2.1
      
      [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
      
      
      
      Fixes: bd55f96f ("kbuild: refactor cc-cross-prefix implementation")
      Cc: linux-stable <stable@vger.kernel.org> # 5.1
      Reported-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      913ab978
  4. Jun 05, 2019
  5. Jun 04, 2019
  6. Jun 01, 2019
  7. May 30, 2019
  8. May 24, 2019
  9. May 22, 2019
  10. May 21, 2019
  11. May 20, 2019
    • Masahiro Yamada's avatar
      kbuild: do not check name uniqueness of builtin modules · 4a33d4f1
      Masahiro Yamada authored
      I just thought it was a good idea to scan builtin.modules in the name
      uniqueness checking, but a couple of false positives were found.
      
      Stephen reported a false positive for ppc64_defconfig:
      
        warning: same basename if the following are built as modules:
          arch/powerpc/platforms/powermac/nvram.ko
          drivers/char/nvram.ko
      
      The former is never built as a module as you see in
      arch/powerpc/platforms/powermac/Makefile:
      
        # CONFIG_NVRAM is an arch. independent tristate symbol, for pmac32 we really
        # need this to be a bool.  Cheat here and pretend CONFIG_NVRAM=m is really
        # CONFIG_NVRAM=y
        obj-$(CONFIG_NVRAM:m=y)         += nvram.o
      
      Another example of false positive is arm64 defconfig:
      
        warning: same basename if the following are built as modules:
          arch/arm64/lib/crc32.ko
          lib/crc32.ko
      
      It is true CONFIG_CRC32 is a tristate option but it is always 'y' since
      it is select'ed by ARM64. Hence, neither of them is built as a module
      for the arm64 build.
      
      From the above, modules.builtin essentially contains false positives.
      I do not think it is a big deal as far as kmod is concerned, but false
      positive warnings in the kernel build make people upset. It is better
      to not check it.
      
      Even without builtin.modules checked, we have enough (and more solid)
      test coverage with allmodconfig.
      
      While I touched this part, I replaced the sed code with neater one
      provided by Stephen.
      
      Link: https://lkml.org/lkml/2019/5/19/120
      Link: https://lkml.org/lkml/2019/5/19/123
      
      
      Fixes: 3a48a919 ("kbuild: check uniqueness of module names")
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a33d4f1
    • Kees Cook's avatar
      gcc-plugins: Fix build failures under Darwin host · 7210e060
      Kees Cook authored
      
      The gcc-common.h file did not take into account certain macros that
      might have already been defined in the build environment. This updates
      the header to avoid redefining the macros, as seen on a Darwin host
      using gcc 4.9.2:
      
       HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o - due to: scripts/gcc-plugins/gcc-common.h
      In file included from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:0:
      scripts/gcc-plugins/gcc-common.h:153:0: warning: "__unused" redefined
      ^
      In file included from /usr/include/stdio.h:64:0,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/system.h:40,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/gcc-plugin.h:28,
                      from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/plugin.h:23,
                      from scripts/gcc-plugins/gcc-common.h:9,
                      from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
      /usr/include/sys/cdefs.h:161:0: note: this is the location of the previous definition
      ^
      
      Reported-and-tested-by: default avatar"H. Nikolaus Schaller" <hns@goldelico.com>
      Fixes: 189af465 ("ARM: smp: add support for per-task stack canaries")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      7210e060
    • Sven Eckelmann's avatar
      scripts/spdxcheck.py: Fix path to deprecated licenses · e6d319f6
      Sven Eckelmann authored
      
      The directory name for other licenses was changed to "deprecated" in
      commit 62be257e ("LICENSES: Rename other to deprecated"). But it was
      not changed for spdxcheck.py. As result, checkpatch failed with
      
        FAIL: "Blob or Tree named 'other' not found"
        Traceback (most recent call last):
          File "scripts/spdxcheck.py", line 240, in <module>
            spdx = read_spdxdata(repo)
          File "scripts/spdxcheck.py", line 41, in read_spdxdata
            for el in lictree[d].traverse():
          File "/usr/lib/python2.7/dist-packages/git/objects/tree.py", line 298, in __getitem__
            return self.join(item)
          File "/usr/lib/python2.7/dist-packages/git/objects/tree.py", line 244, in join
            raise KeyError(msg % file)
        KeyError: "Blob or Tree named 'other' not found"
      
      Fixes: 62be257e ("LICENSES: Rename other to deprecated")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      e6d319f6
    • Nick Desaulniers's avatar
      kbuild: drop support for cc-ldoption · 055efab3
      Nick Desaulniers authored
      
      If you want to see if your linker supports a certain flag, then ask the
      linker directly with ld-option (not the compiler with cc-ldoption).
      Checking for linker flag support is an antipattern that complicates the
      usage of various linkers other than bfd via -fuse-ld={bfd|gold|lld}.
      
      Cc: clang-built-linux@googlegroups.com
      Suggested-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      055efab3
  12. May 19, 2019
  13. May 18, 2019
    • Masahiro Yamada's avatar
      kbuild: check uniqueness of module names · 3a48a919
      Masahiro Yamada authored
      In the recent build test of linux-next, Stephen saw a build error
      caused by a broken .tmp_versions/*.mod file:
      
        https://lkml.org/lkml/2019/5/13/991
      
      
      
      drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same
      basename, and there is a race in generating .tmp_versions/asix.mod
      
      Kbuild has not checked this before, and it suddenly shows up with
      obscure error messages when this kind of race occurs.
      
      Non-unique module names cause various sort of problems, but it is
      not trivial to catch them by eyes.
      
      Hence, this script.
      
      It checks not only real modules, but also built-in modules (i.e.
      controlled by tristate CONFIG option, but currently compiled with =y).
      Non-unique names for built-in modules also cause problems because
      /sys/modules/ would fall over.
      
      For the latest kernel, I tested "make allmodconfig all" (or more
      quickly "make allyesconfig modules"), and it detected the following:
      
      warning: same basename if the following are built as modules:
        drivers/regulator/88pm800.ko
        drivers/mfd/88pm800.ko
      warning: same basename if the following are built as modules:
        drivers/gpu/drm/bridge/adv7511/adv7511.ko
        drivers/media/i2c/adv7511.ko
      warning: same basename if the following are built as modules:
        drivers/net/phy/asix.ko
        drivers/net/usb/asix.ko
      warning: same basename if the following are built as modules:
        fs/coda/coda.ko
        drivers/media/platform/coda/coda.ko
      warning: same basename if the following are built as modules:
        drivers/net/phy/realtek.ko
        drivers/net/dsa/realtek.ko
      
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Reviewed-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
      3a48a919
Loading