15 Sep, 2018

1 commit

  • commit 914b087ff9e0e9a399a4927fa30793064afc0178 upstream.

    When $DEPMOD is not found, only print a warning instead of exiting
    with an error message and error status:

    Warning: 'make modules_install' requires /sbin/depmod. Please install it.
    This is probably in the kmod package.

    Change the Error to a Warning because "not all build hosts for cross
    compiling Linux are Linux systems and are able to provide a working
    port of depmod, especially at the file patch /sbin/depmod."

    I.e., "make modules_install" may be used to copy/install the
    loadable modules files to a target directory on a build system and
    then transferred to an embedded device where /sbin/depmod is run
    instead of it being run on the build system.

    Fixes: 934193a654c1 ("kbuild: verify that $DEPMOD is installed")
    Signed-off-by: Randy Dunlap
    Reported-by: H. Nikolaus Schaller
    Cc: stable@vger.kernel.org
    Cc: Lucas De Marchi
    Cc: Lucas De Marchi
    Cc: Michal Marek
    Cc: Jessica Yu
    Cc: Chih-Wei Huang
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Maxim Zhukov
    Signed-off-by: Greg Kroah-Hartman

    Randy Dunlap
     

18 Aug, 2018

1 commit

  • commit 934193a654c1f4d0643ddbf4b2529b508cae926e upstream.

    Verify that 'depmod' ($DEPMOD) is installed.
    This is a partial revert of commit 620c231c7a7f
    ("kbuild: do not check for ancient modutils tools").

    Also update Documentation/process/changes.rst to refer to
    kmod instead of module-init-tools.

    Fixes kernel bugzilla #198965:
    https://bugzilla.kernel.org/show_bug.cgi?id=198965

    Signed-off-by: Randy Dunlap
    Cc: Lucas De Marchi
    Cc: Lucas De Marchi
    Cc: Michal Marek
    Cc: Jessica Yu
    Cc: Chih-Wei Huang
    Cc: stable@vger.kernel.org # any kernel since 2012
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Greg Kroah-Hartman

    Randy Dunlap
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

22 Feb, 2013

1 commit

  • On architectures which have symbol prefixes, depmod emits lots of
    warnings like this:

    WARNING: $module.ko needs unknown symbol $symbol

    This is because depmod isn't being passed the -P
    arguments to specify the symbol prefix to ignore. This option is
    included since the 3.13 release of module-init-tools.

    Update scripts/depmod.sh to take extra arguments for the symbol prefix
    (required but may be empty), and update the main Makefile to always pass
    "$(CONFIG_SYMBOL_PREFIX)" to scripts/depmod.sh.

    If the provided symbol prefix is non-empty, scripts/depmod.sh checks if
    depmod --version reports module-init-tools with a version number < 3.13
    otherwise it appends -P $SYMBOL_PREFIX to the depmod command line.

    Signed-off-by: James Hogan
    Cc: Michal Marek
    Cc: linux-kbuild@vger.kernel.org
    Cc: Mike Frysinger
    Cc: Yoshinori Sato
    Cc: uclinux-dist-devel@blackfin.uclinux.org
    Signed-off-by: Michal Marek

    James Hogan
     

23 Jan, 2012

1 commit

  • scripts/depmod.sh checks for the output of '-V' expecting that it has
    module-init-tools in it. It's a hack to prevent users from using
    modutils instead of module-init-tools, that only works with 2.4.x
    kernels. This however prints an annoying warning for kmod tool, that is
    currently replacing module-init-tools.

    Rather than putting another check for kmod's version, just remove it
    since users of 2.4.x kernel are unlikely to upgrade to 3.x, and if they
    do, let depmod fail in that case because they should know what they are
    doing.

    Signed-off-by: Lucas De Marchi
    Acked-by: WANG Cong
    Acked-By: Kay Sievers
    Signed-off-by: Michal Marek

    Lucas De Marchi
     

12 Jul, 2011

1 commit


10 Jun, 2011

2 commits