Skip to content
Snippets Groups Projects
  1. May 12, 2020
    • Masahiro Yamada's avatar
      kbuild: determine the output format of DTC by the target suffix · 78046fab
      Masahiro Yamada authored
      
      cmd_dtc takes the additional parameter $(2) to select the target
      format, dtb or yaml. This makes things complicated when it is used
      with cmd_and_fixdep and if_changed_rule. I actually stumbled on this.
      See commit 3d4b2238 ("kbuild: fix DT binding schema rule again to
      avoid needless rebuilds").
      
      Extract the suffix part of the target instead of passing the parameter.
      Fortunately, this works for both $(obj)/%.dtb and $(obj)/%.dt.yaml .
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      78046fab
    • Masahiro Yamada's avatar
      kbuild: use -MMD instead of -MD to exclude system headers from dependency · 30a77297
      Masahiro Yamada authored
      
      This omits system headers from the generated header dependency.
      
      System headers are not updated unless you upgrade the compiler. Nor do
      they contain CONFIG options, so fixdep does not need to parse them.
      
      Having said that, the effect of this optimization will be quite small
      because the kernel code generally does not include system headers
      except <stdarg.h>. Host programs include a lot of system headers,
      but there are not so many in the kernel tree.
      
      At first, keeping system headers in .*.cmd files might be useful to
      detect the compiler update, but there is no guarantee that <stdarg.h>
      is included from every file. So, I implemented a more reliable way in
      the previous commit.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      30a77297
  2. Apr 23, 2020
  3. Mar 03, 2020
  4. Feb 26, 2020
  5. Feb 03, 2020
    • Masahiro Yamada's avatar
      kbuild: rename hostprogs-y/always to hostprogs/always-y · 5f2fb52f
      Masahiro Yamada authored
      
      In old days, the "host-progs" syntax was used for specifying host
      programs. It was renamed to the current "hostprogs-y" in 2004.
      
      It is typically useful in scripts/Makefile because it allows Kbuild to
      selectively compile host programs based on the kernel configuration.
      
      This commit renames like follows:
      
        always       ->  always-y
        hostprogs-y  ->  hostprogs
      
      So, scripts/Makefile will look like this:
      
        always-$(CONFIG_BUILD_BIN2C) += ...
        always-$(CONFIG_KALLSYMS)    += ...
            ...
        hostprogs := $(always-y) $(always-m)
      
      I think this makes more sense because a host program is always a host
      program, irrespective of the kernel configuration. We want to specify
      which ones to compile by CONFIG options, so always-y will be handier.
      
      The "always", "hostprogs-y", "hostprogs-m" will be kept for backward
      compatibility for a while.
      
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      5f2fb52f
  6. Jan 06, 2020
  7. Nov 14, 2019
    • Masahiro Yamada's avatar
      kbuild: remove header compile test · fcbb8461
      Masahiro Yamada authored
      There are both positive and negative options about this feature.
      At first, I thought it was a good idea, but actually Linus stated a
      negative opinion (https://lkml.org/lkml/2019/9/29/227
      
      ). I admit it
      is ugly and annoying.
      
      The baseline I'd like to keep is the compile-test of uapi headers.
      (Otherwise, kernel developers have no way to ensure the correctness
      of the exported headers.)
      
      I will maintain a small build rule in usr/include/Makefile.
      Remove the other header test functionality.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      fcbb8461
  8. Oct 01, 2019
  9. Sep 06, 2019
  10. Sep 04, 2019
    • Masahiro Yamada's avatar
      kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj) · 54b8ae66
      Masahiro Yamada authored
      
      Kbuild provides per-file compiler flag addition/removal:
      
        CFLAGS_<basetarget>.o
        CFLAGS_REMOVE_<basetarget>.o
        AFLAGS_<basetarget>.o
        AFLAGS_REMOVE_<basetarget>.o
        CPPFLAGS_<basetarget>.lds
        HOSTCFLAGS_<basetarget>.o
        HOSTCXXFLAGS_<basetarget>.o
      
      The <basetarget> is the filename of the target with its directory and
      suffix stripped.
      
      This syntax comes into a trouble when two files with the same basename
      appear in one Makefile, for example:
      
        obj-y += foo.o
        obj-y += dir/foo.o
        CFLAGS_foo.o := <some-flags>
      
      Here, the <some-flags> applies to both foo.o and dir/foo.o
      
      The real world problem is:
      
        scripts/kconfig/util.c
        scripts/kconfig/lxdialog/util.c
      
      Both files are compiled into scripts/kconfig/mconf, but only the
      latter should be given with the ncurses flags.
      
      It is more sensible to use the relative path to the Makefile, like this:
      
        obj-y += foo.o
        CFLAGS_foo.o := <some-flags>
        obj-y += dir/foo.o
        CFLAGS_dir/foo.o := <other-flags>
      
      At first, I attempted to replace $(basetarget) with $*. The $* variable
      is replaced with the stem ('%') part in a pattern rule. This works with
      most of cases, but does not for explicit rules.
      
      For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
      explicit rules, so $* will be empty, resulting in ignoring the per-file
      AFLAGS.
      
      I introduced a new variable, target-stem, which can be used also from
      explicit rules.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarMarc Zyngier <maz@kernel.org>
      54b8ae66
    • Masahiro Yamada's avatar
      kbuild: add $(BASH) to run scripts with bash-extension · 858805b3
      Masahiro Yamada authored
      
      CONFIG_SHELL falls back to sh when bash is not installed on the system,
      but nobody is testing such a case since bash is usually installed.
      So, shell scripts invoked by CONFIG_SHELL are only tested with bash.
      
      It makes it difficult to test whether the hashbang #!/bin/sh is real.
      For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is
      false. (I fixed it up)
      
      Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension
      and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may
      not always be set to bash.
      
      Probably, the right thing to do is to introduce BASH, which is bash by
      default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL)
      with $(BASH) for bash scripts.
      
      If somebody tries to add bash-extension to a #!/bin/sh script, it will
      be caught in testing because /bin/sh is a symlink to dash on some major
      distributions.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      858805b3
  11. Aug 21, 2019
  12. Aug 14, 2019
  13. Aug 13, 2019
    • Masahiro Yamada's avatar
      kbuild: move flex and bison rules to Makefile.host · cf8dfd15
      Masahiro Yamada authored
      
      Flex and bison are used for kconfig, dtc, genksyms, all of which are
      host programs. I never imagine the kernel embeds a parser or a lexer.
      
      Move the flex and bison rules to scripts/Makefile.host. This file is
      included only when hostprogs-y etc. is present in the Makefile in the
      directory. So, parsing these rules are skipped in most of directories.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      cf8dfd15
    • Masahiro Yamada's avatar
      kbuild: make bison create C file and header in a single pattern rule · 6ba7dc66
      Masahiro Yamada authored
      We generally expect bison to create not only a C file, but also a
      header, which will be included from the lexer.
      
      Currently, Kbuild generates them in separate rules. So, for instance,
      when building Kconfig, you will notice bison is invoked twice:
      
        HOSTCC  scripts/kconfig/conf.o
        HOSTCC  scripts/kconfig/confdata.o
        HOSTCC  scripts/kconfig/expr.o
        LEX     scripts/kconfig/lexer.lex.c
        YACC    scripts/kconfig/parser.tab.h
        HOSTCC  scripts/kconfig/lexer.lex.o
        YACC    scripts/kconfig/parser.tab.c
        HOSTCC  scripts/kconfig/parser.tab.o
        HOSTCC  scripts/kconfig/preprocess.o
        HOSTCC  scripts/kconfig/symbol.o
        HOSTLD  scripts/kconfig/conf
      
      Make handles such cases nicely in pattern rules [1]. Merge the two
      rules so that one invokcation of bison can generate both of them.
      
        HOSTCC  scripts/kconfig/conf.o
        HOSTCC  scripts/kconfig/confdata.o
        HOSTCC  scripts/kconfig/expr.o
        LEX     scripts/kconfig/lexer.lex.c
        YACC    scripts/kconfig/parser.tab.[ch]
        HOSTCC  scripts/kconfig/lexer.lex.o
        HOSTCC  scripts/kconfig/parser.tab.o
        HOSTCC  scripts/kconfig/preprocess.o
        HOSTCC  scripts/kconfig/symbol.o
        HOSTLD  scripts/kconfig/conf
      
      [1] Pattern rule
      
      GNU Make manual says:
      "Pattern rules may have more than one target. Unlike normal rules,
      this does not act as many different rules with the same prerequisites
      and recipe. If a pattern rule has multiple targets, make knows that
      the rule's recipe is responsible for making all of the targets. The
      recipe is executed only once to make all the targets. When searching
      for a pattern rule to match a target, the target patterns of a rule
      other than the one that matches the target in need of a rule are
      incidental: make worries only about giving a recipe and prerequisites
      to the file presently in question. However, when this file's recipe is
      run, the other targets are marked as having been updated themselves."
      
      https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html
      
      
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      6ba7dc66
  14. Jul 27, 2019
  15. Jul 17, 2019
  16. Jul 10, 2019
  17. Jul 09, 2019
    • Masahiro Yamada's avatar
      kbuild: support header-test-pattern-y · 1e21cbfa
      Masahiro Yamada authored
      
      In my view, most of headers can be self-contained. So, it would be
      tedious to add every header to header-test-y explicitly. We usually
      end up with "all headers with some exceptions".
      
      There are two types in exceptions:
      
      [1] headers that are never compiled as standalone units
      
        For examples, include/linux/compiler-gcc.h is not intended for
        direct inclusion. We should always exclude such ones.
      
      [2] headers that are conditionally compiled as standalone units
      
        Some headers can be compiled only for particular architectures.
        For example, include/linux/arm-cci.h can be compiled only for
        arm/arm64 because it requires <asm/arm-cci.h> to exist.
        Clang can compile include/soc/nps/mtm.h only for arc because
        it contains an arch-specific register in inline assembler.
      
      So, you can write Makefile like this:
      
        header-test-                += linux/compiler-gcc.h
        header-test-$(CONFIG_ARM)   += linux/arm-cci.h
        header-test-$(CONFIG_ARM64) += linux/arm-cci.h
        header-test-$(CONFIG_ARC)   += soc/nps/mtm.h
      
      The new syntax header-test-pattern-y will be useful to specify
      "the rest".
      
      The typical usage is like this:
      
        header-test-pattern-y += */*.h
      
      This will add all the headers in sub-directories to the test coverage,
      excluding $(header-test-). In this regards, header-test-pattern-y
      behaves like a weaker variant of header-test-y.
      
      Caveat:
      The patterns in header-test-pattern-y are prefixed with $(srctree)/$(src)/
      but not $(objtree)/$(obj)/. Stale generated headers are often left over
      when you traverse the git history without cleaning. Wildcard patterns for
      $(objtree) may match to stale headers, which could fail to compile.
      One pitfall is $(srctree)/$(src)/ and $(objtree)/$(obj)/ point to the
      same directory for in-tree building. So, header-test-pattern-y should
      be used with care since it can potentially match to stale headers.
      
      Caveat2:
      You could use wildcard for header-test-. For example,
      
        header-test- += asm-generic/%
      
      ... will exclude headers in asm-generic directory. Unfortunately, the
      wildcard character is '%' instead of '*' here because this is evaluated
      by $(filter-out ...) whereas header-test-pattern-y is evaluated by
      $(wildcard ...). This is a kludge, but seems useful in some places...
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarJani Nikula <jani.nikula@intel.com>
      1e21cbfa
    • Masahiro Yamada's avatar
      kbuild: do not create wrappers for header-test-y · c93a0368
      Masahiro Yamada authored
      
      header-test-y does not work with headers in sub-directories.
      
      For example, you may want to write a Makefile, like this:
      
      include/linux/Kbuild:
      
        header-test-y += mtd/nand.h
      
      This entry will create a wrapper include/linux/mtd/nand.hdrtest.c
      with the following content:
      
        #include "mtd/nand.h"
      
      To make this work, we need to add $(srctree)/include/linux to the
      header search path. It would be tedious to add ccflags-y.
      
      Instead, we could change the *.hdrtest.c rule to wrap:
      
        #include "nand.h"
      
      This works for in-tree build since #include "..." searches in the
      relative path from the header with this directive. For O=... build,
      we need to add $(srctree)/include/linux/mtd to the header search path,
      which will be even more tedious.
      
      After all, I thought it would be handier to compile headers directly
      without creating wrappers.
      
      I added a new build rule to compile %.h into %.h.s
      
      The target is %.h.s instead of %.h.o because it is slightly faster.
      Also, as for GCC, an empty assembly is smaller than an empty object.
      
      I wrote the build rule:
      
        $(CC) $(c_flags) -S -o $@ -x c /dev/null -include $<
      
      instead of:
      
        $(CC) $(c_flags) -S -o $@ -x c $<
      
      Both work fine with GCC, but the latter is bad for Clang.
      
      This comes down to the difference in the -Wunused-function policy.
      GCC does not warn about unused 'static inline' functions at all.
      Clang does not warn about the ones in included headers, but does
      about the ones in the source. So, we should handle headers as
      headers, not as source files.
      
      In fact, this has been hidden since commit abb2ea7d ("compiler,
      clang: suppress warning for unused static inline functions"), but we
      should not rely on that.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarJani Nikula <jani.nikula@intel.com>
      Tested-by: default avatarJani Nikula <jani.nikula@intel.com>
      c93a0368
  18. Jun 15, 2019
  19. May 22, 2019
  20. May 18, 2019
  21. Apr 02, 2019
    • Masahiro Yamada's avatar
      kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build · a9a49c2a
      Masahiro Yamada authored
      
      KBUILD_SRC was conventionally used for some different purposes:
       [1] To remember the source tree path
       [2] As a flag to check if sub-make is already done
       [3] As a flag to check if Kbuild runs out of tree
      
      For [1], we do not need to remember it because the top Makefile
      can compute it by $(realpath $(dir $(lastword $(MAKEFILE_LIST))))
      
      [2] has been replaced with self-commenting 'sub_make_done'.
      
      For [3], we can distinguish in-tree/out-of-tree by comparing
      $(srctree) and '.'
      
      This commit converts [3] to prepare for the KBUILD_SRC removal.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      a9a49c2a
  22. Mar 13, 2019
  23. Jan 28, 2019
  24. Jan 06, 2019
  25. Dec 13, 2018
    • Rob Herring's avatar
      kbuild: Add support for DT binding schema checks · 4f0e3a57
      Rob Herring authored
      
      This adds the build infrastructure for checking DT binding schema
      documents and validating dts files using the binding schema.
      
      Check DT binding schema documents:
      make dt_binding_check
      
      Build dts files and check using DT binding schema:
      make dtbs_check
      
      Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
      use for validation. This makes it easier to find and fix errors
      generated by a specific schema.
      
      Currently, the validation targets are separate from a normal build to
      avoid a hard dependency on the external DT schema project and because
      there are lots of warnings generated.
      
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: linux-doc@vger.kernel.org
      Cc: devicetree@vger.kernel.org
      Cc: linux-kbuild@vger.kernel.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      4f0e3a57
  26. Dec 01, 2018
Loading