Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 06 7月, 2019 1 次提交
  3. 09 6月, 2019 4 次提交
  5. 07 6月, 2019 1 次提交
    • M
      kbuild: use more portable 'command -v' for cc-cross-prefix · 913ab978
      由 Masahiro Yamada 提交于 
      To print the pathname that will be used by shell in the current
environment, 'command -v' is a standardized way. [1]

'which' is also often used in scripts, but it is less portable.

When I worked on commit bd55f96f ("kbuild: refactor cc-cross-prefix
implementation"), I was eager to use 'command -v' but it did not work.
(The reason is explained below.)

I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
thought it was no longer needed. Sorry, I was wrong.

It works well on my Ubuntu machine, but Alexey Brodkin reports noisy
warnings on CentOS7 when 'which' fails to find the given command in
the PATH environment.

  $ which foo
  which: no foo in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

Given that behavior of 'which' depends on system (and it may not be
installed by default), I want to try 'command -v' once again.

The specification [1] clearly describes the behavior of 'command -v'
when the given command is not found:

  Otherwise, no output shall be written and the exit status shall reflect
  that the name was not found.

However, we need a little magic to use 'command -v' from Make.

$(shell ...) passes the argument to a subshell for execution, and
returns the standard output of the command.

Here is a trick. GNU Make may optimize this by executing the command
directly instead of forking a subshell, if no shell special characters
are found in the command and omitting the subshell will not change the
behavior.

In this case, no shell special character is used. So, Make will try
to run it directly. However, 'command' is a shell-builtin command,
then Make would fail to find it in the PATH environment:

  $ make ARCH=m68k defconfig
  make: command: Command not found
  make: command: Command not found
  make: command: Command not found

In fact, Make has a table of shell-builtin commands because it must
ask the shell to execute them.

Until recently, 'command' was missing in the table.

This issue was fixed by the following commit:

| commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
| Author: Paul Smith <psmith@gnu.org>
| Date:   Sun Nov 12 18:10:28 2017 -0500
|
|     * job.c: Add "command" as a known shell built-in.
|
|     This is not a POSIX shell built-in but it's common in UNIX shells.
|     Reported by Nick Bowler <nbowler@draconx.ca>.

Because the latest release is GNU Make 4.2.1 in 2016, this commit is
not included in any released versions. (But some distributions may
have back-ported it.)

We need to trick Make to spawn a subshell. There are various ways to
do so:

 1) Use a shell special character '~' as dummy

    $(shell : ~; command -v $(c)gcc)

 2) Use a variable reference that always expands to the empty string
    (suggested by David Laight)

    $(shell command$${x:+} -v $(c)gcc)

 3) Use redirect

    $(shell command -v $(c)gcc 2>/dev/null)

I chose 3) to not confuse people. The stderr would not be polluted
anyway, but it will provide extra safety, and is easy to understand.

Tested on Make 3.81, 3.82, 4.0, 4.1, 4.2, 4.2.1

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

Fixes: bd55f96f ("kbuild: refactor cc-cross-prefix implementation")
Cc: linux-stable <stable@vger.kernel.org> # 5.1
Reported-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: NAlexey Brodkin <abrodkin@synopsys.com>
      913ab978
  7. 05 6月, 2019 10 次提交
  9. 02 6月, 2019 2 次提交
  11. 31 5月, 2019 6 次提交
  13. 24 5月, 2019 4 次提交
  15. 23 5月, 2019 1 次提交
  17. 22 5月, 2019 1 次提交
  19. 21 5月, 2019 6 次提交
    • S
      scripts/spdxcheck.py: Add dual license subdirectory · 29077bc5
      由 Sven Eckelmann 提交于 
      The licenses from the other directory were partially moved to the dual
directory in commit 8ea8814f ("LICENSES: Clearly mark dual license only
licenses"). checkpatch therefore rejected files like
drivers/staging/android/ashmem.h with

  WARNING: 'SPDX-License-Identifier: GPL-2.0 OR Apache-2.0 */' is not supported in LICENSES/...
  #1: FILE: drivers/staging/android/ashmem.h:1:
  +/* SPDX-License-Identifier: GPL-2.0 OR Apache-2.0 */

Fixes: 8ea8814f ("LICENSES: Clearly mark dual license only licenses")
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      29077bc5
    • T
      treewide: Add SPDX license identifier - Makefile/Kconfig · ec8f24b7
      由 Thomas Gleixner 提交于 
      Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec8f24b7
    • T
      treewide: Add SPDX license identifier for missed files · 457c8996
      由 Thomas Gleixner 提交于 
      Add SPDX license identifiers to all files which:

 - Have no license information of any form

 - Have EXPORT_.*_SYMBOL_GPL inside which was used in the
   initial scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      457c8996
    • M
      kbuild: do not check name uniqueness of builtin modules · 4a33d4f1
      由 Masahiro Yamada 提交于 
      I just thought it was a good idea to scan builtin.modules in the name
uniqueness checking, but a couple of false positives were found.

Stephen reported a false positive for ppc64_defconfig:

  warning: same basename if the following are built as modules:
    arch/powerpc/platforms/powermac/nvram.ko
    drivers/char/nvram.ko

The former is never built as a module as you see in
arch/powerpc/platforms/powermac/Makefile:

  # CONFIG_NVRAM is an arch. independent tristate symbol, for pmac32 we really
  # need this to be a bool.  Cheat here and pretend CONFIG_NVRAM=m is really
  # CONFIG_NVRAM=y
  obj-$(CONFIG_NVRAM:m=y)         += nvram.o

Another example of false positive is arm64 defconfig:

  warning: same basename if the following are built as modules:
    arch/arm64/lib/crc32.ko
    lib/crc32.ko

It is true CONFIG_CRC32 is a tristate option but it is always 'y' since
it is select'ed by ARM64. Hence, neither of them is built as a module
for the arm64 build.

From the above, modules.builtin essentially contains false positives.
I do not think it is a big deal as far as kmod is concerned, but false
positive warnings in the kernel build make people upset. It is better
to not check it.

Even without builtin.modules checked, we have enough (and more solid)
test coverage with allmodconfig.

While I touched this part, I replaced the sed code with neater one
provided by Stephen.

Link: https://lkml.org/lkml/2019/5/19/120
Link: https://lkml.org/lkml/2019/5/19/123
Fixes: 3a48a919 ("kbuild: check uniqueness of module names")
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a33d4f1
    • K
      gcc-plugins: Fix build failures under Darwin host · 7210e060
      由 Kees Cook 提交于 
      The gcc-common.h file did not take into account certain macros that
might have already been defined in the build environment. This updates
the header to avoid redefining the macros, as seen on a Darwin host
using gcc 4.9.2:

 HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o - due to: scripts/gcc-plugins/gcc-common.h
In file included from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:0:
scripts/gcc-plugins/gcc-common.h:153:0: warning: "__unused" redefined
^
In file included from /usr/include/stdio.h:64:0,
                from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/system.h:40,
                from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/gcc-plugin.h:28,
                from /Users/hns/Documents/Projects/QuantumSTEP/System/Library/Frameworks/System.framework/Versions-jessie/x86_64-apple-darwin15.0.0/gcc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.2/plugin/include/plugin.h:23,
                from scripts/gcc-plugins/gcc-common.h:9,
                from scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
/usr/include/sys/cdefs.h:161:0: note: this is the location of the previous definition
^
Reported-and-tested-by: N"H. Nikolaus Schaller" <hns@goldelico.com>
Fixes: 189af465 ("ARM: smp: add support for per-task stack canaries")
Cc: stable@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>
      7210e060
    • S
      scripts/spdxcheck.py: Fix path to deprecated licenses · e6d319f6
      由 Sven Eckelmann 提交于 
      The directory name for other licenses was changed to "deprecated" in
commit 62be257e ("LICENSES: Rename other to deprecated"). But it was
not changed for spdxcheck.py. As result, checkpatch failed with

  FAIL: "Blob or Tree named 'other' not found"
  Traceback (most recent call last):
    File "scripts/spdxcheck.py", line 240, in <module>
      spdx = read_spdxdata(repo)
    File "scripts/spdxcheck.py", line 41, in read_spdxdata
      for el in lictree[d].traverse():
    File "/usr/lib/python2.7/dist-packages/git/objects/tree.py", line 298, in __getitem__
      return self.join(item)
    File "/usr/lib/python2.7/dist-packages/git/objects/tree.py", line 244, in join
      raise KeyError(msg % file)
  KeyError: "Blob or Tree named 'other' not found"

Fixes: 62be257e ("LICENSES: Rename other to deprecated")
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      e6d319f6
  21. 20 5月, 2019 1 次提交
  23. 19 5月, 2019 1 次提交
  25. 18 5月, 2019 2 次提交
    • M
      kbuild: check uniqueness of module names · 3a48a919
      由 Masahiro Yamada 提交于 
      In the recent build test of linux-next, Stephen saw a build error
caused by a broken .tmp_versions/*.mod file:

  https://lkml.org/lkml/2019/5/13/991

drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same
basename, and there is a race in generating .tmp_versions/asix.mod

Kbuild has not checked this before, and it suddenly shows up with
obscure error messages when this kind of race occurs.

Non-unique module names cause various sort of problems, but it is
not trivial to catch them by eyes.

Hence, this script.

It checks not only real modules, but also built-in modules (i.e.
controlled by tristate CONFIG option, but currently compiled with =y).
Non-unique names for built-in modules also cause problems because
/sys/modules/ would fall over.

For the latest kernel, I tested "make allmodconfig all" (or more
quickly "make allyesconfig modules"), and it detected the following:

warning: same basename if the following are built as modules:
  drivers/regulator/88pm800.ko
  drivers/mfd/88pm800.ko
warning: same basename if the following are built as modules:
  drivers/gpu/drm/bridge/adv7511/adv7511.ko
  drivers/media/i2c/adv7511.ko
warning: same basename if the following are built as modules:
  drivers/net/phy/asix.ko
  drivers/net/usb/asix.ko
warning: same basename if the following are built as modules:
  fs/coda/coda.ko
  drivers/media/platform/coda/coda.ko
warning: same basename if the following are built as modules:
  drivers/net/phy/realtek.ko
  drivers/net/dsa/realtek.ko
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
      3a48a919
    • A
      kconfig: Terminate menu blocks with a comment in the generated config · aff11cd9
      由 Alexander Popov 提交于 
      Currently menu blocks start with a pretty header but end with nothing in
the generated config. So next config options stick together with the
options from the menu block.

Let's terminate menu blocks in the generated config with a comment and
a newline if needed. Example:

...
CONFIG_BPF_STREAM_PARSER=y
CONFIG_NET_FLOW_LIMIT=y

#
# Network testing
#
CONFIG_NET_PKTGEN=y
CONFIG_NET_DROP_MONITOR=y
# end of Network testing
# end of Networking options

CONFIG_HAMRADIO=y
...
Signed-off-by: NAlexander Popov <alex.popov@linux.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      aff11cd9