An error occurred fetching the project authors.
  1. 25 Feb, 2024 1 commit
  2. 18 Feb, 2024 1 commit
  3. 14 Feb, 2024 1 commit
  4. 11 Feb, 2024 1 commit
  5. 04 Feb, 2024 1 commit
  6. 31 Jan, 2024 2 commits
  7. 29 Jan, 2024 1 commit
  8. 21 Jan, 2024 3 commits
  9. 07 Jan, 2024 1 commit
  10. 31 Dec, 2023 1 commit
  11. 29 Dec, 2023 1 commit
    • Masahiro Yamada's avatar
      kbuild: resolve symlinks for O= properly · 7beba04e
      Masahiro Yamada authored
      Currently, Kbuild follows the logical chain of directories for the O=
      option, just like 'cd' (or 'realpath --logical') does.
      
      Example:
      
          $ mkdir -p /tmp/a /tmp/x/y
          $ ln -s /tmp/x/y /tmp/a/b
          $ realpath /tmp/a/b/..
          /tmp/x
          $ realpath --logical /tmp/a/b/..
          /tmp/a
          $ make O=/tmp/a/b/.. defconfig
          make[1]: Entering directory '/tmp/a'
            [snip]
          make[1]: Leaving directory '/tmp/a'
      
      'make O=/tmp/a/b/.. defconfig' creates the kernel configuration in
      /tmp/a instead of /tmp/x despite /tmp/a/b/.. resolves to /tmp/x.
      
      This is because Kbuild internally uses the 'cd ... && pwd' for the
      path resolution, but this behavior is not predictable for users.
      Additionally, it is not consistent with how the Kbuild handles the
      M= option or GNU Make works with 'make -C /tmp/a/b/..'.
      
      Using the physical directory structure for the O= option seems more
      reasonable.
      
      The comment says "expand a shell special character '~'", but it has
      already been expanded to the home directory in the command line.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      7beba04e
  12. 24 Dec, 2023 1 commit
  13. 17 Dec, 2023 1 commit
  14. 11 Dec, 2023 1 commit
  15. 10 Dec, 2023 1 commit
  16. 03 Dec, 2023 2 commits
    • Linus Torvalds's avatar
      Linux 6.7-rc4 · 33cc938e
      Linus Torvalds authored
      33cc938e
    • Masahiro Yamada's avatar
      kbuild: support W=c and W=e shorthands for Kconfig · 92ef432f
      Masahiro Yamada authored
      KCONFIG_WARN_UNKNOWN_SYMBOLS=1 and KCONFIG_WERROR=1 are descriptive
      and suitable in scripting, but typing them from the command line can
      be tedious.
      
      Associate them with KBUILD_EXTRA_WARN (and the W= shorthand).
      
      Support a new letter 'c' to enable extra checks in Kconfig. You can
      still manage compiler warnings (W=1) and Kconfig warnings (W=c)
      independently.
      
      Reuse the letter 'e' to turn Kconfig warnings into errors.
      
      As usual, you can combine multiple letters in KCONFIG_EXTRA_WARN.
      
        $ KCONFIG_WARN_UNKNOWN_SYMBOLS=1 KCONFIG_WERROR=1 make defconfig
      
      can be shortened to:
      
        $ KBUILD_EXTRA_WARN=ce make defconfig
      
      or, even shorter:
      
        $ make W=ce defconfig
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNathan Chancellor <nathan@kernel.org>
      92ef432f
  17. 28 Nov, 2023 1 commit
  18. 27 Nov, 2023 1 commit
  19. 19 Nov, 2023 1 commit
  20. 13 Nov, 2023 1 commit
  21. 30 Oct, 2023 1 commit
  22. 28 Oct, 2023 4 commits
    • Simon Glass's avatar
      kbuild: Correct missing architecture-specific hyphens · 766b7007
      Simon Glass authored
      These should add a hyphen to indicate that it makes a adjective. Fix
      them.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      766b7007
    • Masahiro Yamada's avatar
      kbuild: avoid too many execution of scripts/pahole-flags.sh · 72d09184
      Masahiro Yamada authored
      scripts/pahole-flags.sh is executed so many times.
      
      You can confirm it, as follows:
      
        $ cat <<EOF >> scripts/pahole-flags.sh
        > echo "scripts/pahole-flags.sh was executed" >&2
        > EOF
      
        $ make -s
        scripts/pahole-flags.sh was executed
        scripts/pahole-flags.sh was executed
        scripts/pahole-flags.sh was executed
        scripts/pahole-flags.sh was executed
        scripts/pahole-flags.sh was executed
          [ lots of repeated lines... ]
      
      This scripts is executed more than 20 times during the kernel build
      because PAHOLE_FLAGS is a recursively expanded variable and exported
      to sub-processes.
      
      With GNU Make >= 4.4, it is executed more than 60 times because
      exported variables are also passed to other $(shell ) invocations.
      Without careful coding, it is known to cause an exponential fork
      explosion. [1]
      
      The use of $(shell ) in an exported recursive variable is likely wrong
      because $(shell ) is always evaluated due to the 'export' keyword, and
      the evaluation can occur multiple times by the nature of recursive
      variables.
      
      Convert the shell script to a Makefile, which is included only when
      CONFIG_DEBUG_INFO_BTF=y.
      
      [1]: https://savannah.gnu.org/bugs/index.php?64746Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarAlan Maguire <alan.maguire@oracle.com>
      Tested-by: default avatarAlan Maguire <alan.maguire@oracle.com>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      Tested-by: default avatarMiguel Ojeda <ojeda@kernel.org>
      Acked-by: default avatarMiguel Ojeda <ojeda@kernel.org>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Reviewed-by: default avatarMartin Rodriguez Reboredo <yakoyoku@gmail.com>
      72d09184
    • Masahiro Yamada's avatar
      kbuild: unify no-compiler-targets and no-sync-config-targets · 9d361173
      Masahiro Yamada authored
      Now that vdso_install does not depend on any in-tree build artifact,
      it no longer needs a compiler, making no-compiler-targets the same
      as no-sync-config-targets.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <nicolas@fjasle.eu>
      9d361173
    • Masahiro Yamada's avatar
      kbuild: unify vdso_install rules · 56769ba4
      Masahiro Yamada authored
      Currently, there is no standard implementation for vdso_install,
      leading to various issues:
      
       1. Code duplication
      
          Many architectures duplicate similar code just for copying files
          to the install destination.
      
          Some architectures (arm, sparc, x86) create build-id symlinks,
          introducing more code duplication.
      
       2. Unintended updates of in-tree build artifacts
      
          The vdso_install rule depends on the vdso files to install.
          It may update in-tree build artifacts. This can be problematic,
          as explained in commit 19514fc6 ("arm, kbuild: make
          "make install" not depend on vmlinux").
      
       3. Broken code in some architectures
      
          Makefile code is often copied from one architecture to another
          without proper adaptation.
      
          'make vdso_install' for parisc does not work.
      
          'make vdso_install' for s390 installs vdso64, but not vdso32.
      
      To address these problems, this commit introduces a generic vdso_install
      rule.
      
      Architectures that support vdso_install need to define vdso-install-y
      in arch/*/Makefile. vdso-install-y lists the files to install.
      
      For example, arch/x86/Makefile looks like this:
      
        vdso-install-$(CONFIG_X86_64)           += arch/x86/entry/vdso/vdso64.so.dbg
        vdso-install-$(CONFIG_X86_X32_ABI)      += arch/x86/entry/vdso/vdsox32.so.dbg
        vdso-install-$(CONFIG_X86_32)           += arch/x86/entry/vdso/vdso32.so.dbg
        vdso-install-$(CONFIG_IA32_EMULATION)   += arch/x86/entry/vdso/vdso32.so.dbg
      
      These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
      if exists, stripped away.
      
      vdso-install-y can optionally take the second field after the colon
      separator. This is needed because some architectures install a vdso
      file as a different base name.
      
      The following is a snippet from arch/arm64/Makefile.
      
        vdso-install-$(CONFIG_COMPAT_VDSO)      += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
      
      This will rename vdso.so.dbg to vdso32.so during installation. If such
      architectures change their implementation so that the base names match,
      this workaround will go away.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390
      Reviewed-by: default avatarNicolas Schier <nicolas@fjasle.eu>
      Reviewed-by: default avatarGuo Ren <guoren@kernel.org>
      Acked-by: Helge Deller <deller@gmx.de>  # parisc
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      56769ba4
  23. 22 Oct, 2023 1 commit
  24. 19 Oct, 2023 1 commit
  25. 15 Oct, 2023 1 commit
  26. 08 Oct, 2023 1 commit
  27. 05 Oct, 2023 2 commits
  28. 03 Oct, 2023 1 commit
  29. 01 Oct, 2023 1 commit
  30. 24 Sep, 2023 1 commit
  31. 17 Sep, 2023 1 commit
  32. 11 Sep, 2023 1 commit