1. 27 Jul, 2019 1 commit
  2. 17 Jul, 2019 1 commit
    • Masahiro Yamada's avatar
      kbuild: create *.mod with full directory path and remove MODVERDIR · b7dca6dd
      Masahiro Yamada authored
      While descending directories, Kbuild produces objects for modules,
      but do not link final *.ko files; it is done in the modpost.
      To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
      for every module it is building. Some post-processing steps read the
      necessary information from *.mod files. This avoids descending into
      directories again. This mechanism was introduced in 2003 or so.
      Later, commit 551559e1 ("kbuild: implement modules.order") added
      modules.order. So, we can simply read it out to know all the modules
      with directory paths. This is easier than parsing the first line of
      *.mod files.
      $(MODVERDIR) has a flat directory structure, that is, *.mod files
      are named only with base names. This is based on the assumption that
      the module name is unique across the tree. This assumption is really
      Stephen Rothwell reported a race condition caused by a module name
      In parallel building, two different threads could write to the same
      $(MODVERDIR)/*.mod simultaneously.
      Non-unique module names are the source of all kind of troubles, hence
      commit 3a48a919 ("kbuild: check uniqueness of module names")
      introduced a new checker script.
      However, it is still fragile in the build system point of view because
      this race happens before scripts/modules-check.sh is invoked. If it
      happens again, the modpost will emit unclear error messages.
      To fix this issue completely, create *.mod with full directory path
      so that two threads never attempt to write to the same file.
      $(MODVERDIR) is no longer needed.
      Since modules with directory paths are listed in modules.order, Kbuild
      is still able to find *.mod files without additional descending.
      I also killed cmd_secanalysis; scripts/mod/sumversion.c computes MD4 hash
      it occurs not only in the modpost stage, but also during directory
      descending, where sumversion.c may parse stale *.mod files. It would emit
      'No such file or directory' warning when an object consisting a module is
      renamed, or when a single-obj module is turned into a multi-obj module or
      vice versa.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarNicolas Pitre <nico@fluxnic.net>
  3. 09 Jul, 2019 1 commit
    • 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:
        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>
  4. 15 Jun, 2019 1 commit
  5. 18 May, 2019 1 commit
  6. 08 May, 2019 1 commit
  7. 07 May, 2019 2 commits
    • Alexey Gladkov's avatar
      moduleparam: Save information about built-in modules in separate file · 898490c0
      Alexey Gladkov authored
      When a kernel module is compiled as a separate module, some important
      information about the kernel module is available via .modinfo section of
      the module.  In contrast, when the kernel module is compiled into the
      kernel, that information is not available.
      Information about built-in modules is necessary in the following cases:
      1. When it is necessary to find out what additional parameters can be
      passed to the kernel at boot time.
      2. When you need to know which module names and their aliases are in
      the kernel. This is very useful for creating an initrd image.
      The proposed patch does not remove .modinfo section with module
      information from the vmlinux at the build time and saves it into a
      separate file after kernel linking. So, the kernel does not increase in
      size and no additional information remains in it. Information is stored
      in the same format as in the separate modules (null-terminated string
      array). Because the .modinfo section is already exported with a separate
      modules, we are not creating a new API.
      It can be easily read in the userspace:
      $ tr '\0' '\n' < modules.builtin.modinfo
      ext4.softdep=pre: crc32c
      ext4.description=Fourth Extended Filesystem
      ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
      md_mod.description=MD RAID framework
      Co-Developed-by: default avatarGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
      Signed-off-by: default avatarGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
      Signed-off-by: default avatarAlexey Gladkov <gladkov.alexey@gmail.com>
      Acked-by: default avatarJessica Yu <jeyu@kernel.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
    • Masahiro Yamada's avatar
      .gitignore: add leading and trailing slashes to generated directories · 1e35663e
      Masahiro Yamada authored
      Clarify these directory paths are relative to the top of the source
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  8. 13 Dec, 2018 1 commit
    • 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>
  9. 11 Apr, 2018 1 commit
    • Miguel Ojeda's avatar
      clang-format: add configuration file · d4ef8d3f
      Miguel Ojeda authored
      clang-format is a tool to format C/C++/...  code according to a set of
      rules and heuristics.  Like most tools, it is not perfect nor covers
      every single case, but it is good enough to be helpful.
      In particular, it is useful for quickly re-formatting blocks of code
      automatically, for reviewing full files in order to spot coding style
      mistakes, typos and possible improvements.  It is also handy for sorting
      ``#includes``, for aligning variables and macros, for reflowing text and
      other similar tasks.  It also serves as a teaching tool/guide for
      The tool itself has been already included in the repositories of popular
      Linux distributions for a long time.  The rules in this file are
      intended for clang-format >= 4, which is easily available in most
      This commit adds the configuration file that contains the rules that the
      tool uses to know how to format the code according to the kernel coding
      style.  This gives us several advantages:
        * clang-format works out of the box with reasonable defaults;
          avoiding that everyone has to re-do the configuration.
        * Everyone agrees (eventually) on what is the most useful default
          configuration for most of the kernel.
        * If it becomes commonplace among kernel developers, clang-format
          may feel compelled to support us better. They already recognize
          the Linux kernel and its style in their documentation and in one
          of the style sub-options.
      Some of clang-format's features relevant for the kernel are:
        * Uses clang's tooling support behind the scenes to parse and rewrite
          the code. It is not based on ad-hoc regexps.
        * Supports reasonably well the Linux kernel coding style.
        * Fast enough to be used at the press of a key.
        * There are already integrations (either built-in or third-party)
          for many common editors used by kernel developers (e.g. vim,
          emacs, Sublime, Atom...) that allow you to format an entire file
          or, more usefully, just your selection.
        * Able to parse unified diffs -- you can, for instance, reformat
          only the lines changed by a git commit.
        * Able to reflow text comments as well.
        * Widely supported and used by hundreds of developers in highly
          complex projects and organizations (e.g. the LLVM project itself,
          Chromium, WebKit, Google, Mozilla...). Therefore, it will be
          supported for a long time.
      See more information about the tool at:
      Link: http://lkml.kernel.org/r/20180318171632.qfkemw3mwbcukth6@gmail.comSigned-off-by: default avatarMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 07 Apr, 2018 3 commits
  11. 25 Mar, 2018 1 commit
  12. 14 Feb, 2018 1 commit
  13. 12 Dec, 2017 1 commit
    • Paolo Pisati's avatar
      scripts/package: snap-pkg target · 5704d455
      Paolo Pisati authored
      Following in footsteps of other targets like 'deb-pkg, 'rpm-pkg' and 'tar-pkg',
      this patch adds a 'snap-pkg' target for the creation of a Linux kernel snap
      package using the kbuild infrastructure.
      A snap, in its general form, is a self contained, sandboxed, universal package
      and it is intended to work across multiple distributions and/or devices. A snap
      package is distributed as a single compressed squashfs filesystem.
      A kernel snap is a snap package carrying the Linux kernel, kernel modules,
      accessory files (DTBs, System.map, etc) and a manifesto file.  The purpose of a
      kernel snap is to carry the Linux kernel during the creation of a system image,
      eg. Ubuntu Core, and its subsequent upgrades.
      For more information on snap packages: https://snapcraft.io/docs/Signed-off-by: default avatarPaolo Pisati <paolo.pisati@canonical.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  14. 14 Nov, 2017 1 commit
  15. 08 Nov, 2017 2 commits
  16. 24 Apr, 2017 1 commit
  17. 22 Jul, 2016 1 commit
    • Luis R. Rodriguez's avatar
      scripts: add Linux .cocciconfig for coccinelle · dd951fc1
      Luis R. Rodriguez authored
      Coccinelle supports reading .cocciconfig, the order of precedence for
      variables for .cocciconfig is as follows:
       o Your current user's home directory is processed first
       o Your directory from which spatch is called is processed next
       o The directory provided with the --dir option is processed last, if used
      Since coccicheck runs through make, it naturally runs from the kernel
      proper dir, as such the second rule above would be implied for picking up a
      .cocciconfig when using 'make coccicheck'.
      'make coccicheck' also supports using M= targets.If you do not supply
      any M= target, it is assumed you want to target the entire kernel.
      The kernel coccicheck script has:
          if [ "$KBUILD_EXTMOD" = "" ] ; then
              OPTIONS="--dir $srctree $COCCIINCLUDE"
      KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases
      the spatch --dir argument is used, as such third rule applies when
      whether M= is used or not, and when M= is used the target directory can
      have its own .cocciconfig file. When M= is not passed as an argument to
      coccicheck the target directory is the same as the directory from where
      spatch was called.
      If not using the kernel's coccicheck target, keep the above precedence order
      logic of .cocciconfig reading. If using the kernel's coccicheck target,
      override any of the kernel's .coccicheck's settings using SPFLAGS.
      We help Coccinelle when used against Linux with a set of sensible defaults
      options for Linux with our own Linux .cocciconfig. This hints to coccinelle
      git can be used for 'git grep' queries over coccigrep. A timeout of 200
      seconds should suffice for now.
      The options picked up by coccinelle when reading a .cocciconfig do not appear
      as arguments to spatch processes running on your system, to confirm what
      options will be used by Coccinelle run:
        spatch --print-options-only
      You can override with your own preferred index option by using SPFLAGS.
      Coccinelle supports both glimpse and idutils. Glimpse had historically
      provided the best performance, however recent benchmarks reveal idutils
      is performing just as well. Due to some recent fixes however you however
      will need at least coccinelle >= 1.0.6 if using idutils.
      Coccinelle carries a script scripts/idutils_index.sh which creates the
      idutils database with as follows:
          mkid -i C --output .id-utils.index
      If using just "--use-idutils" coccinelle expects your idutils database to be
      on the top level of the kernel as a file named ".id-utils.index". If you do
      not use this you can symlink your database file to it, or you can specify the
      database file following the "--use-idutils" argument. Examples:
          make SPFLAGS=--use-idutils coccicheck
      This assumes you have $srctree/.id-utils.index, where $srctree is
      the top level of the kernel.
          make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck
      Here you specify the full path of the idutils ID database. Using
      .cocciconfig is possible, however given the order of precedence followed
      by Coccinelle, and since the kernel now carries its own .cocciconfig,
      you will need to use SPFLAGS to use idutils if desired.
      o Recommend upgrade for using idutils with coccinelle due to some
        recent fixes.
      o Refer to using --print-options-only for testing what options are
        picked up by .cocciconfig reading.
      o Expand commit log considerably explaining *why* .cocconfig from
        two precedence rules are used when using coccicheck, and how to
        properly override these if needed.
      o Expand Documentation/coccinelle.txt
      v3: Expand commit log a bit more
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Acked-by: default avatarJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  18. 07 Jun, 2016 1 commit
    • Emese Revfy's avatar
      GCC plugin infrastructure · 6b90bd4b
      Emese Revfy authored
      This patch allows to build the whole kernel with GCC plugins. It was ported from
      grsecurity/PaX. The infrastructure supports building out-of-tree modules and
      building in a separate directory. Cross-compilation is supported too.
      Currently the x86, arm, arm64 and uml architectures enable plugins.
      The directory of the gcc plugins is scripts/gcc-plugins. You can use a file or a directory
      there. The plugins compile with these options:
       * -fno-rtti: gcc is compiled with this option so the plugins must use it too
       * -fno-exceptions: this is inherited from gcc too
       * -fasynchronous-unwind-tables: this is inherited from gcc too
       * -ggdb: it is useful for debugging a plugin (better backtrace on internal
       * -Wno-narrowing: to suppress warnings from gcc headers (ipa-utils.h)
       * -Wno-unused-variable: to suppress warnings from gcc headers (gcc_version
          variable, plugin-version.h)
      The infrastructure introduces a new Makefile target called gcc-plugins. It
      supports all gcc versions from 4.5 to 6.0. The scripts/gcc-plugin.sh script
      chooses the proper host compiler (gcc-4.7 can be built by either gcc or g++).
      This script also checks the availability of the included headers in
      The gcc-common.h header contains frequently included headers for GCC plugins
      and it has a compatibility layer for the supported gcc versions.
      The gcc-generate-*-pass.h headers automatically generate the registration
      structures for GIMPLE, SIMPLE_IPA, IPA and RTL passes.
      Note that 'make clean' keeps the *.so files (only the distclean or mrproper
      targets clean all) because they are needed for out-of-tree modules.
      Based on work created by the PaX Team.
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  19. 28 Apr, 2016 1 commit
  20. 28 Aug, 2015 1 commit
  21. 07 Aug, 2015 1 commit
    • David Woodhouse's avatar
      modsign: Use single PEM file for autogenerated key · fb117949
      David Woodhouse authored
      The current rule for generating signing_key.priv and signing_key.x509 is
      a classic example of a bad rule which has a tendency to break parallel
      make. When invoked to create *either* target, it generates the other
      target as a side-effect that make didn't predict.
      So let's switch to using a single file signing_key.pem which contains
      both key and certificate. That matches what we do in the case of an
      external key specified by CONFIG_MODULE_SIG_KEY anyway, so it's also
      slightly cleaner.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  22. 15 Jun, 2015 2 commits
  23. 17 Apr, 2015 1 commit
  24. 17 Feb, 2015 1 commit
  25. 13 Feb, 2015 1 commit
  26. 27 Nov, 2014 1 commit
  27. 25 Nov, 2014 1 commit
  28. 27 Oct, 2014 1 commit
  29. 30 Jul, 2014 1 commit
    • Andi Kleen's avatar
      kbuild: Support split debug info v4 · 866ced95
      Andi Kleen authored
      This is an alternative approach to lower the overhead of debug info
      (as we discussed a few days ago)
      gcc 4.7+ and newer binutils have a new "split debug info" debug info
      model where the debug info is only written once into central ".dwo" files.
      This avoids having to copy it around multiple times, from the object
      files to the final executable. It lowers the disk space
      requirements. In addition it defaults to compressed debug data.
      More details here: http://gcc.gnu.org/wiki/DebugFission
      This patch adds a new option to enable it. It has to be an option,
      because it'll undoubtedly break everyone's debuginfo packaging scheme.
      gdb/objdump/etc. all still work, if you have new enough versions.
      I don't see big compile wins (maybe a second or two faster or so), but the
      object dirs with debuginfo get significantly smaller. My standard kernel
      config (slightly bigger than defconfig) shrinks from 2.9G disk space
      to 1.1G objdir (with non reduced debuginfo). I presume if you are IO limited
      the compile time difference will be larger.
      Only problem I've seen so far is that it doesn't play well with older
      versions of ccache (apparently fixed, see
      v2: various fixes from Dirk Gouders. Improve commit message slightly.
      v3: Fix clean rules and improve Kconfig slightly
      v4: Fix merge error in last version (Sam Ravnborg)
          Clarify description that it mainly helps disk size.
      Cc: Dirk Gouders <dirk@gouders.net>
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  30. 16 Apr, 2014 1 commit
  31. 11 Feb, 2014 1 commit
  32. 31 Jul, 2013 1 commit
  33. 18 Dec, 2012 1 commit
  34. 19 Oct, 2012 1 commit
  35. 10 Oct, 2012 1 commit