26 Mar, 2020
1 commit
-
Overlapping header include additions in macsec.c
A bug fix in 'net' overlapping with the removal of 'version'
string in ena_netdev.cOverlapping test additions in selftests Makefile
Overlapping PCI ID table adjustments in iwlwifi driver.
Signed-off-by: David S. Miller
10 Mar, 2020
1 commit
-
With fentry/fexit programs, it is possible to profile BPF program with
hardware counters. Introduce bpftool "prog profile", which measures key
metrics of a BPF program.bpftool prog profile command creates per-cpu perf events. Then it attaches
fentry/fexit programs to the target BPF program. The fentry program saves
perf event value to a map. The fexit program reads the perf event again,
and calculates the difference, which is the instructions/cycles used by
the target program.Example input and output:
./bpftool prog profile id 337 duration 3 cycles instructions llc_misses
4228 run_cnt
3403698 cycles (84.08%)
3525294 instructions # 1.04 insn per cycle (84.05%)
13 llc_misses # 3.69 LLC misses per million isns (83.50%)This command measures cycles and instructions for BPF program with id
337 for 3 seconds. The program has triggered 4228 times. The rest of the
output is similar to perf-stat. In this example, the counters were only
counting ~84% of the time because of time multiplexing of perf counters.Note that, this approach measures cycles and instructions in very small
increments. So the fentry/fexit programs introduce noticeable errors to
the measurement results.The fentry/fexit programs are generated with BPF skeletons. Therefore, we
build bpftool twice. The first time _bpftool is built without skeletons.
Then, _bpftool is used to generate the skeletons. The second time, bpftool
is built with skeletons.Signed-off-by: Song Liu
Signed-off-by: Daniel Borkmann
Reviewed-by: Quentin Monnet
Acked-by: Yonghong Song
Link: https://lore.kernel.org/bpf/20200309173218.2739965-2-songliubraving@fb.com
07 Mar, 2020
1 commit
-
When I tried to compile tools/perf from the top directory with the -C
option, the O= option didn't work correctly if I passed a relative path:$ make O=BUILD -C tools/perf/
make: Entering directory '/home/mhiramat/ksrc/linux/tools/perf'
BUILD: Doing 'make -j8' parallel build
../scripts/Makefile.include:4: *** O=/home/mhiramat/ksrc/linux/tools/perf/BUILD does not exist. Stop.
make: *** [Makefile:70: all] Error 2
make: Leaving directory '/home/mhiramat/ksrc/linux/tools/perf'The O= directory existence check failed because the check script ran in
the build target directory instead of the directory where I ran the make
command.To fix that, once change directory to $(PWD) and check O= directory,
since the PWD is set to where the make command runs.Fixes: c883122acc0d ("perf tools: Let O= makes handle relative paths")
Reported-by: Randy Dunlap
Signed-off-by: Masami Hiramatsu
Cc: Andrew Morton
Cc: Borislav Petkov
Cc: Geert Uytterhoeven
Cc: Jiri Olsa
Cc: Masahiro Yamada
Cc: Michal Marek
Cc: Peter Zijlstra
Cc: Sasha Levin
Cc: Steven Rostedt (VMware)
Cc: stable@vger.kernel.org
Link: http://lore.kernel.org/lkml/158351957799.3363.15269768530697526765.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo
23 Jul, 2019
1 commit
-
As it is too strict, see https://lkml.org/lkml/2006/11/28/253 and
https://gcc.gnu.org/gcc-4.8/changes.html, that takes into account
Linus's comments (search for Wshadow) for the reasoning about -Wshadow
not being interesting before gcc 4.8.Acked-by: Andrii Nakryiko
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Link: https://lkml.kernel.org/r/20190719183417.GQ3624@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
10 Apr, 2018
1 commit
-
I tried building using a freshly built Make (4.2.1-69-g8a731d1), but
already the objtool build broke withorc_dump.c: In function ‘orc_dump’:
orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations]
if (elf_getshdrnum(elf, &nr_sections)) {Turns out that with that new Make, the backslash was not removed, so cpp
didn't see a #include directive, grep found nothing, and
-DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS.Now, that new Make behaviour is documented in their NEWS file:
* WARNING: Backward-incompatibility!
Number signs (#) appearing inside a macro reference or function invocation
no longer introduce comments and should not be escaped with backslashes:
thus a call such as:
foo := $(shell echo '#')
is legal. Previously the number sign needed to be escaped, for example:
foo := $(shell echo '\#')
Now this latter will resolve to "\#". If you want to write makefiles
portable to both versions, assign the number sign to a variable:
C := \#
foo := $(shell echo '$C')
This was claimed to be fixed in 3.81, but wasn't, for some reason.
To detect this change search for 'nocomment' in the .FEATURES variable.This also fixes up the two make-cmd instances to replace # with $(pound)
rather than with \#. There might very well be other places that need
similar fixup in preparation for whatever future Make release contains
the above change, but at least this builds an x86_64 defconfig with the
new make.Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847
Cc: Randy Dunlap
Signed-off-by: Rasmus Villemoes
Signed-off-by: Masahiro Yamada
16 Mar, 2018
1 commit
-
The Tile architecture port was added by Chris Metcalf in 2010, and
maintained until early 2018 when he orphaned it due to his departure
from Mellanox, and nobody else stepped up to maintain it. The product
line is still around in the form of the BlueField SoC, but no longer
uses the Tile architecture.There are also still products for sale with Tile-GX SoCs, notably the
Mikrotik CCR router family. The products all use old (linux-3.3) kernels
with lots of patches and won't be upgraded by their manufacturers. There
have been efforts to port both OpenWRT and Debian to these, but both
projects have stalled and are very unlikely to be continued in the future.Given that we are reasonably sure that nobody is still using the port
with an upstream kernel any more, it seems better to remove it now while
the port is in a good shape than to let it bitrot for a few years first.Cc: Chris Metcalf
Cc: John Paul Adrian Glaubitz
Link: http://www.mellanox.com/page/npu_multicore_overview
Link: https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_tilegx_gcc7/
Signed-off-by: Arnd Bergmann
22 Feb, 2018
1 commit
-
Currently a number of Makefiles break when used with toolchains that
pass extra flags in CC and other cross-compile related variables (such
as --sysroot).Thus we get this error when we use a toolchain that puts --sysroot in
the CC var:~/src/linux/tools$ make iio
[snip]
iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory
#include
^~~~~~~~~~This occurs because we clobber several env vars related to
cross-compiling with lines like this:CC = $(CROSS_COMPILE)gcc
Although this will point to a valid cross-compiler, we lose any extra
flags that might exist in the CC variable, which can break toolchains
that rely on them (for example, those that use --sysroot).This easily shows up using a Yocto SDK:
$ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi
$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
-mcpu=cortex-a8
--sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi$ echo $CROSS_COMPILE
arm-poky-linux-gnueabi-$ echo ${CROSS_COMPILE}gcc
krm-poky-linux-gnueabi-gccAlthough arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the
--sysroot and other flags that enable us to find the right libraries to
link against, so we can't find unistd.h and other libraries and headers.
Normally with the --sysroot flag we would find unistd.h in the sdk
directory in the sysroot:$ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h'
[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.hThe perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not
already set, and it compiles correctly with the above toolchain.So, generalize the logic that perf uses in the common Makefile and
remove the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile.Note that this patch does not fix cross-compile for all the tools (some
have other bugs), but it does fix it for all except usb and acpi, which
still have other unrelated issues.I tested both with and without the patch on native and cross-build and
there appear to be no regressions.Link: http://lkml.kernel.org/r/20180107214028.23771-1-martin@martingkelly.com
Signed-off-by: Martin Kelly
Acked-by: Mark Brown
Cc: Tejun Heo
Cc: Li Zefan
Cc: Johannes Weiner
Cc: Linus Walleij
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Jonathan Cameron
Cc: Pali Rohar
Cc: Richard Purdie
Cc: Jacek Anaszewski
Cc: Pavel Machek
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Robert Moore
Cc: Lv Zheng
Cc: "Rafael J. Wysocki"
Cc: Greg Kroah-Hartman
Cc: Valentina Manea
Cc: Shuah Khan
Cc: Mario Limonciello
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 Dec, 2017
1 commit
-
Create two targets to remove executable and documentation that would
have been previously installed with `make install` and `make
doc-install`.Also create a "QUIET_UNINST" helper in tools/scripts/Makefile.include.
Do not attempt to remove directories /usr/local/sbin and
/usr/share/bash-completions/completions, even if they are empty, as
those specific directories probably already existed on the system before
we installed the program, and we do not wish to break other makefiles
that might assume their existence. Do remvoe /usr/local/share/man/man8
if empty however, as this directory does not seem to exist by default.Signed-off-by: Quentin Monnet
Signed-off-by: Daniel Borkmann
18 Nov, 2017
1 commit
-
Most places use pwd and rely on $PATH lookup. Moving the remaining
absolute path /bin/pwd users over for consistency.Also, a reason for doing /bin/pwd -> pwd instead of the other way around
is because I believe build systems should make little assumptions on
host filesystem layout. Case in point, we do this kind of patching
already in NixOS.Ref. commit 028568d84da3cfca49f5f846eeeef01441d70451
("kbuild: revert $(realpath ...) to $(shell cd ... && /bin/pwd)").Signed-off-by: Bjørn Forsman
Signed-off-by: Masahiro Yamada
03 Nov, 2017
1 commit
-
…el/git/gregkh/driver-core
Pull initial SPDX identifiers from Greg KH:
"License cleanup: add SPDX license identifiers to some filesMany 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 <5
lines).All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that
was:SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that
became the concluded license(s).- when there was disagreement between the two scanners (one detected
a license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply
(and which scanner probably needed to revisit its heuristics).- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases,
confirmation by lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.
The Windriver scanner is based on an older version of FOSSology in
part, so they are related.Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot
checks in about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect
the correct identifier.Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial
patch version early this week with:- a full scancode scan run, collecting the matched texts, detected
license ids and scores- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct- reviewing anything where there was no detection but the patch
license was not GPL-2.0 WITH Linux-syscall-note to ensure that the
applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"* tag 'spdx_identifiers-4.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
License cleanup: add SPDX license identifier to uapi header files with a license
License cleanup: add SPDX license identifier to uapi header files with no license
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
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
07 Oct, 2017
1 commit
-
I thought commit 8e9b46679923 ("kbuild: use $(abspath ...) instead of
$(shell cd ... && /bin/pwd)") was a safe conversion, but it changed
the behavior.$(abspath ...) / $(realpath ...) does not expand shell special
characters, such as '~'.Here is a simple Makefile example:
---------------->8----------------
$(info /bin/pwd: $(shell cd ~/; /bin/pwd))
$(info abspath: $(abspath ~/))
$(info realpath: $(realpath ~/))
all:
@:
---------------->8----------------$ make
/bin/pwd: /home/masahiro
abspath: /home/masahiro/workspace/~
realpath:This can be a real problem if 'make O=~/foo' is invoked from another
Makefile or primitive shell like dash.This commit partially reverts 8e9b46679923.
Fixes: 8e9b46679923 ("kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)")
Reported-by: Julien Grall
Signed-off-by: Masahiro Yamada
Tested-by: Julien Grall
15 Sep, 2017
1 commit
-
Pull Kbuild updates from Masahiro Yamada:
- Use Make-builtin $(abspath ...) helper to get absolute path
- Add W=2 extra warning option to detect unused macros
- Use more KCONFIG_CONFIG instead hard-coded .config
- Fix bugs of tar*-pkg targets
* tag 'kbuild-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: buildtar: do not print successful message if tar returns error
kbuild: buildtar: fix tar error when CONFIG_MODULES is disabled
kbuild: Use KCONFIG_CONFIG in buildtar
Kbuild: enable -Wunused-macros warning for "make W=2"
kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)
01 Sep, 2017
1 commit
-
Kbuild conventionally uses $(shell cd ... && /bin/pwd) idiom to get
the absolute path of the directory because GNU Make 3.80, the minimal
supported version at that time, did not support $(abspath ...) or
$(realpath ...).Commit 37d69ee30808 ("docs: bump minimal GNU Make version to 3.81")
dropped the GNU Make 3.80 support, so we are now allowed to use those
make-builtin helpers.This conversion will provide better portability without relying on
the pwd command or its location /bin/pwd.I am intentionally using $(realpath ...) instead $(abspath ...) in
some places. The difference between the two is $(realpath ...)
returns an empty string if the given path does not exist. It is
convenient in places where we need to error-out if the makefile fails
to create an output directory.Signed-off-by: Masahiro Yamada
Acked-by: Thierry Reding
29 Aug, 2017
1 commit
-
Prior to this patch, make scripts tested for CLANG with ifeq ($(CC),
clang), failing to detect CLANG binaries with different names. Fix it by
testing for the existence of __clang__ macro in the list of compiler
defined macros.Signed-off-by: David Carrillo-Cisneros
Acked-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Paul Turner
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/20170827075442.108534-5-davidcc@google.com
Signed-off-by: Arnaldo Carvalho de Melo
06 Jun, 2017
1 commit
-
This allows to detect -s (--silent) option without checking GNU Make
version.As commit e36aaea28972 ("kbuild: Fix silent builds with make-4")
pointed out, GNU Make 4.x changed the way/order it presents the
command line options into MAKEFLAGS.In Make 3.8x, 's' is always the first in a group of short options.
The group may be prefixed with '-' in some cases.In Make 4.x, 's' is always the last in a group of short options.
As commit e6ac89fabd03 ("kbuild: Correctly deal with make options
which contain an 's'") addressed, we also need to deal with long
options that contain 's', like --warn-undefined-variables.Test cases:
[1] command line input: make --silent
-> MAKEFLAGS for Make 3.8x: s
-> MAKEFLAGS for Make 4.x : s[2] command line input: make -srR
-> MAKEFLAGS for Make 3.8x: sRr
-> MAKEFLAGS for Make 4.x : rRs[3] command line input: make -s -rR --warn-undefined-variables
-> MAKEFLAGS for Make 3.8x: --warn-undefined-variables -sRr
-> MAKEFLAGS for Make 4.x : rRs --warn-undefined-variablesMy idea to cater to all the cases more easily is to filter out long
options (--%), then search 's' with $(findstring ...). This way will
be more future-proof even if future versions of Make put 's' in the
middle of the group.Signed-off-by: Masahiro Yamada
04 Mar, 2017
1 commit
-
Will be included from atomic.h and used in refcount.h
Cc: Adrian Hunter
Cc: David Ahern
Cc: Elena Reshetova
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-pzrydfee75mhq64kazxmf9it@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
14 Feb, 2017
1 commit
-
To allow building with clang, avoiding:
error: unknown warning option '-Wstrict-aliasing=3'; did you mean '-Wstring-plus-int'? [-Werror,-Wunknown-warning-option]
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-xvthlvmhzfnt7jx73jgmaea1@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
27 Jan, 2017
1 commit
-
When doing a kernel build with 'make -s', everything is silenced except
the objtool build. That's because the tools tree support for silent
builds is some combination of missing and broken.Three changes are needed to fix it:
- Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
tools Makefiles can see it.- tools/scripts/Makefile.include: fix the tools Makefiles' ability to
recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from
the top-level Makefile. This silences the "DESCEND objtool" message.- tools/build/Makefile.build: add support to the tools Build files for
recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are
copied from the top-level Makefile. This silences all the object
compile/link messages.Reported-and-Tested-by: Peter Zijlstra
Signed-off-by: Josh Poimboeuf
Cc: Jiri Olsa
Cc: Michal Marek
Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
23 Jul, 2016
2 commits
-
The objtool build fails in a cross-compiled environment on a non-x86
host with "ARCH=x86_64":tools/objtool/objtool-in.o: In function `decode_instructions':
tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'We could override the ARCH environment variable and change it back to
x86, similar to what the objtool Makefile was doing before; but it's
tricky to override environment variables consistently.Instead, take a similar approach used by the Linux top-level Makefile
and introduce a SRCARCH Makefile variable which evaluates to "x86" when
ARCH is either "x86_64" or "x86".Reported-by: Stephen Rothwell
Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: H. Peter Anvin
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20160722191920.ej62fnspnqurbaa7@treble
Signed-off-by: Arnaldo Carvalho de Melo -
For tools that needs to be always compiled with the host headers.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jiri Olsa
Cc: Josh Poimboeuf
Cc: Namhyung Kim
Cc: Stephen Rothwell
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-907q32k2nep6q670dkxypmu6@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
19 Mar, 2016
1 commit
-
As it is used by several other tools, better move it outside tools/perf.
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Josh Poimboeuf
Cc: Namhyung Kim
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-34s9kue3xq9w5mijdmfrfx8s@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
12 Jan, 2016
1 commit
-
After this patch other directories can use this architecture detector
without directly including it from perf's directory. Libbpf would
utilize it to get proper $(ARCH) so it can receive correct uapi include
directory.Tested-by: Naveen N. Rao
Acked-by: Jiri Olsa
Cc: Sukadev Bhattiprolu
Cc: Zefan Li
Cc: pi3orama@163.com
Signed-off-by: Wang Nan
Link: http://lkml.kernel.org/r/1452520124-2073-8-git-send-email-wangnan0@huawei.com
[ Add missing srctree definition in tests/make ]
Signed-off-by: Arnaldo Carvalho de Melo
20 Dec, 2013
2 commits
-
Adding global QUIET_CC_FPIC build output variable and getting rid of
local print_fpic_compile and print_plugin_obj_compile.Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/1387460527-15030-6-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo -
Moving QUIET_(CLEAN|INSTAL) variables into:
tools/scripts/Makefile.include
to be usable by other tools. The change to use them in libtraceevent is
in following patches.Signed-off-by: Jiri Olsa
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/1387460527-15030-3-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
11 Oct, 2013
2 commits
-
The various build lines from libtraceevent and perf mix up during a
parallel build and produce unaligned output like:CC builtin-buildid-list.o
CC builtin-buildid-cache.o
CC builtin-list.o
CC FPIC trace-seq.o
CC builtin-record.o
CC FPIC parse-filter.o
CC builtin-report.o
CC builtin-stat.o
CC FPIC parse-utils.o
CC FPIC kbuffer-parse.o
CC builtin-timechart.o
CC builtin-top.o
CC builtin-script.o
BUILD STATIC LIB libtraceevent.a
CC builtin-probe.o
CC builtin-kmem.o
CC builtin-lock.oTo solve this, harmonize all the build message alignments to be similar
to the kernel's kbuild output: prefixed by two spaces and 11-char wide.After the patch the output looks pretty tidy, even if output lines get
mixed up:CC builtin-annotate.o
FLAGS: * new build flags or cross compiler
CC builtin-bench.o
AR liblk.a
CC bench/sched-messaging.o
CC FPIC event-parse.o
CC bench/sched-pipe.o
CC FPIC trace-seq.o
CC bench/mem-memcpy.o
CC bench/mem-memset.o
CC FPIC parse-filter.o
CC builtin-diff.o
CC builtin-evlist.o
CC builtin-help.oSigned-off-by: Ingo Molnar
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1381312169-17354-3-git-send-email-mingo@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo -
'make clean' used to show all the rm lines, which isn't really
informative in any way and spams the console.Implement summary output:
comet:~/tip/tools/perf> make clean
CLEAN libtraceevent
CLEAN liblk
CLEAN config
CLEAN core-objs
CLEAN core-progs
CLEAN core-gen
CLEAN Documentation
CLEAN python'make clean V=1' will still show the old, detailed output.
Signed-off-by: Ingo Molnar
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1381312169-17354-2-git-send-email-mingo@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
09 Jul, 2013
1 commit
-
Fix having verbose build with V=0, e.g:
make V=0 -C tools/ perf
Signed-off-by: Robert Richter
Link: http://lkml.kernel.org/r/20130503134953.GU8356@rric.localhost
Signed-off-by: Arnaldo Carvalho de Melo
16 Mar, 2013
2 commits
-
It looks at O= and adjusts the $(OUTPUT) variable based on what the
output directory will be. However, when O is defined but empty, it
wrongly becomes the user's $HOME dir which is not what we want. So check
it is not empty before working with it further.Signed-off-by: Borislav Petkov
Cc: Ingo Molnar
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/1361374353-30385-4-git-send-email-bp@alien8.de
Signed-off-by: Arnaldo Carvalho de Melo -
We need to hand down parallel build options like the internal make
--jobserver-fds one so that parallel builds can also happen when
building perf from the toplevel directory.Make it so #1!
Signed-off-by: Borislav Petkov
Cc: Ingo Molnar
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/1361374353-30385-3-git-send-email-bp@alien8.de
Signed-off-by: Arnaldo Carvalho de Melo
20 Nov, 2012
3 commits
-
Fixing:
[acme@sandy linux]$ cd tools
[acme@sandy tools]$ make clean
DESCEND power/cpupower
CC lib/cpufreq.o
CC lib/sysfs.o
LD libcpupower.so.0.0.0
CC utils/helpers/amd.o
utils/helpers/amd.c:7:21: error: pci/pci.h: No such file or directory
In file included from utils/helpers/amd.c:9:
./utils/helpers/helpers.h:137: warning: ‘struct pci_access’ declared inside parameter list
./utils/helpers/helpers.h:137: warning: its scope is only this definition or declaration, which is probably not what you want
./utils/helpers/helpers.h:139: warning: ‘struct pci_access’ declared inside parameter list
utils/helpers/amd.c: In function ‘amd_pci_get_num_boost_states’:
utils/helpers/amd.c:120: warning: passing argument 1 of ‘pci_slot_func_init’ from incompatible pointer type
./utils/helpers/helpers.h:138: note: expected ‘struct pci_access **’ but argument is of type ‘struct pci_access **’
utils/helpers/amd.c:125: warning: implicit declaration of function ‘pci_read_byte’
utils/helpers/amd.c:132: warning: implicit declaration of function ‘pci_cleanup’
make[1]: *** [utils/helpers/amd.o] Error 1
make: *** [cpupower_clean] Error 2
[acme@sandy tools]$Reported-by: Arnaldo Carvalho de Melo
Signed-off-by: David Howells
Cc: Borislav Petkov
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/n/tip-tviyimq6x6nm77sj5lt4t19f@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo -
Honour the O= flag that was passed to a higher level Makefile and then passed
down as part of a tool build.To make this work, the top-level Makefile passes the original O= flag and
subdir=tools to the tools/Makefile, and that in turn passes
subdir=$(O)/$(subdir)/foodir when building tool foo in directory
$(O)/$(subdir)/foodir (where the intervening slashes aren't added if an
element is missing).For example, take perf. This is found in tools/perf/. Assume we're building
into directory ~/zebra/, so we pass O=~/zebra to make. Dependening on where
we run the build from, we see:make run in dir $(OUTPUT) dir
======================= ==================
linux ~/zebra/tools/perf/
linux/tools ~/zebra/perf/
linux/tools/perf ~/zebra/and if O= is not set, we get:
make run in dir $(OUTPUT) dir
======================= ==================
linux linux/tools/perf/
linux/tools linux/tools/perf/
linux/tools/perf linux/tools/perf/The output directories are created by the descend function if they don't
already exist.Signed-off-by: David Howells
Cc: Borislav Petkov
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.uk
Signed-off-by: Arnaldo Carvalho de Melo -
Define a Makefile function that can be called with $(call ...) to wrap
the subdir make invocations in tools/Makefile.This will allow us in the next patch to insert bits in there to honour
O= flags when called from the top-level Makefile.Signed-off-by: David Howells
Cc: Borislav Petkov
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.uk
Signed-off-by: Arnaldo Carvalho de Melo
17 Aug, 2012
1 commit
-
When I did a compile of perf using a relative path for the output
directory, the build failed when it tried to compile libtraceevent. This
is because it continues to use the same relative path when the new
working directory is in a different path.SUBDIR ../lib/traceevent/
/bin/sh: line 0: cd: ../../../nobackup/perf/: No such file or directory
Makefile:74: *** output directory "../../../nobackup/perf/" does not exist. Stop.
make: *** [../../../nobackup/perf///libtraceevent.a] Error 2Make the path used an absolute path when building perf with O=.
Boris:
Teach Makefile to check whether the supplied O= directory exists and
bail out if not. Reportedly, kernel dudes are idiots and need to be
guarded so as not to shoot themselves in the foot when playing in the
sandbox.Signed-off-by: Borislav Petkov
Signed-off-by: Steven Rostedt
Acked-by: Steven Rostedt
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20120815163923.GD15989@aftab.osrc.amd.com
Signed-off-by: Arnaldo Carvalho de Melo
25 Apr, 2012
1 commit
-
Have building perf also build libtraceevent.a. Currently, perf does
not use the code within libtraceevent.a, but it soon will.Signed-off-by: Steven Rostedt
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Steven Rostedt
Cc: Borislav Petkov
Cc: Jiri Olsa
Cc: Arun Sharma
Cc: Namhyung Kim
Signed-off-by: Frederic Weisbecker
12 Apr, 2012
2 commits
-
Use += instead of the bash syntax, as Sam Ravnborg suggests. Also, sort
the -W options alphabetically and (... keep them sorted).Suggested-by: Sam Ravnborg
Signed-off-by: Borislav Petkov
Cc: Ingo Molnar
Cc: Michal Marek
Cc: Sam Ravnborg
Link: http://lkml.kernel.org/r/1334162178-17152-3-git-send-email-bp@amd64.org
Signed-off-by: Arnaldo Carvalho de Melo -
Put generic enough build settings which could be reused by other tools
into a common Makefile.include file.This commit reintroduces QUIET_SUBDIR{0,1} (see a3d1ee10d1bf) which are
going to be used in the following patches.Signed-off-by: Borislav Petkov
Cc: Ingo Molnar
Cc: Michal Marek
Cc: Sam Ravnborg
Link: http://lkml.kernel.org/r/1334162178-17152-2-git-send-email-bp@amd64.org
Signed-off-by: Arnaldo Carvalho de Melo
