Skip to content
Snippets Groups Projects
  1. Mar 03, 2020
  2. Jul 17, 2019
    • Masahiro Yamada's avatar
      kbuild: remove the first line of *.mod files · 60ae1b19
      Masahiro Yamada authored
      
      The current format of *.mod is like this:
      
        line 1: directory path to the .ko file
        line 2: a list of objects linked into this module
        line 3: unresolved symbols (only when CONFIG_TRIM_UNUSED_KSYMS=y)
      
      Now that *.mod and *.ko are created in the same directory, the line 1
      provides no valuable information. It can be derived by replacing the
      extension .mod with .ko. In fact, nobody uses the first line any more.
      
      Cut down the first line.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      60ae1b19
    • 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
      fragile.
      
      Stephen Rothwell reported a race condition caused by a module name
      conflict:
      
        https://lkml.org/lkml/2019/5/13/991
      
      
      
      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
      for modules with MODULE_VERSION(). When CONFIG_DEBUG_SECTION_MISMATCH=y,
      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>
      b7dca6dd
  3. Jun 19, 2019
  4. Mar 13, 2019
  5. May 17, 2018
  6. Mar 25, 2018
  7. Mar 21, 2018
  8. Dec 11, 2016
  9. May 10, 2016
  10. Mar 29, 2016
    • Nicolas Pitre's avatar
      kbuild: create/adjust generated/autoksyms.h · 23121ca2
      Nicolas Pitre authored
      
      Given the list of exported symbols needed by all modules, we can create
      a header file containing preprocessor defines for each of those symbols.
      Also, when some symbols are added and/or removed from the list, we can
      update the time on the corresponding files used as build dependencies for
      those symbols. And finally, if any symbol did change state, the
      corresponding source files must be rebuilt.
      
      The insertion or removal of an EXPORT_SYMBOL() entry within a module may
      create or remove the need for another exported symbol.  This is why this
      operation has to be repeated until the list of needed exported symbols
      becomes stable. Only then the final kernel and modules link take place.
      
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      23121ca2
Loading