buildroot/linux/linux-tool-perf.mk, branch 2017.08

linux/tools: make it a real, separate package

2016-09-22T10:32:34+00:00

The kernel source tree also contains the sources for various userland tools, of which cpupower, perf or selftests. Currently, we have support for building those tools as part of the kernel build procedure. This looked the correct thing to do so far, because, well, they *are* part of the kernel source tree and some really have to be the same version as the kernel that will run. However, this is causing quite a non-trivial-to-break circular dependency in some configurations. For example, this defconfig fails to build (similar to the one reported by Paul): BR2_arm=y BR2_cortex_a7=y BR2_ARM_FPU_NEON_VFPV4=y BR2_TOOLCHAIN_EXTERNAL=y BR2_INIT_SYSTEMD=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_GIT=y BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git" BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f" BR2_LINUX_KERNEL_DEFCONFIG="bcm2709" BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y BR2_PACKAGE_CRYPTODEV=y BR2_PACKAGE_OPENSSL=y BR2_PACKAGE_LIBCURL=y This causes a circular dependency, as explained by Thomas: - When libcurl is enabled, systemd depends on it - When OpenSSL is enabled, obviously, will use it for SSL support - When cryptodev-linux is enabled, OpenSSL will depend on it to use crypto accelerators supported in the kernel via cryptodev-linux. - cryptodev-linux being a kernel module, it depends on linux - linux by itself (the kernel) does not depend on pciutils, but the linux tool "cpupower" (managed in linux-tool-cpupower) depends on pciutils - pciutils depends on udev when available - udev is provided by systemd. And indeed, during the build, we can see that make warns (it's only reported as a *warning*, not as an actual error): [...] make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured <- cryptodev-linux dependency dropped. >>> openssl 1.0.2h Downloading [...] So the build fails later on, when openssl is actually built: eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory compilation terminated. : recipe for target 'eng_cryptodev.o' failed Furthermore, graph-depends also detects the circular dependency, but treats it as a hard-error: Recursion detected for : cryptodev-linux which is a dependency of: openssl which is a dependency of: libcurl which is a dependency of: systemd which is a dependency of: udev which is a dependency of: pciutils which is a dependency of: linux which is a dependency of: cryptodev-linux Makefile:738: recipe for target 'graph-depends' failed Of course, there is no way to break the loop without losing functionality in either one of the involved packages *and* keep our infrastructure and packages as-is. The only solution is to break the loop at the linux-tools level, by moving them away into their own package, so that the linux package will no longer have the opportunity to depend on another package via a dependency of one the tools. All three linux tools are thus moved away to their own package. The package infrastructure only knows of three types of packages: those in package/ , in boot/ , in toolchain/ and the one in linux/ . So we create that new linux-tools package in package/ so that we don't have to fiddle with yet another special case in the infra. Still, we want its configure options to appear in the kernel's sub-menu. So, we make it a prompt-less package, with only the tools visible as options of that package, but without the usual dependency on their master symbol; they only depend on the Linux kernel. Furthermore, because the kernel is such a huge pile of code, we would not be very happy to extract it a second time just for the sake of a few tools. We can't extract only the tools/ sub-directory from the kernel source either, because some tools have hard-coded path to includes from the kernel (arch and stuff). Instead, we just use the linux source tree as our own build tree, and ensure the linux tree is extracted and patched before linux-tools is configured and built. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Paul Ashford [Thomas: - fix typo #(@D) -> $(@D) - fix the inclusion of the per-tool .mk files.] Signed-off-by: Thomas Petazzoni

linux/perf: conditionally enable support for gz/xz compression

2016-03-19T13:38:14+00:00

Signed-off-by: "Yann E. MORIN" Cc: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

linux/perf: forcefully disable the features with missing dependencies

2016-03-19T13:38:06+00:00

Forcefully disable the features that have optional dependencies that are not enabled in Buildroot. Disable support for bionic since, well, we're not Android. Slightly re-order the variables to have semantically-related variables together, with features last. Signed-off-by: "Yann E. MORIN" Cc: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

linux/perf: honour the number of parallel jobs

2016-03-19T13:37:32+00:00

perf does not honour the -j flags we pass to make; it yet again tries to reinvent the wheel and by default uses the number of CPUs as the number of parallel jobs. Fortunately, in their infinite wisdom, the insane developpers of the perf buildsystem were kind enough to provide us with a variable we can set to specify the number of parallel jobs. Signed-off-by: "Yann E. MORIN" Cc: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

linux/perf: really do not build the documentation

2016-03-19T13:37:17+00:00

The perf buildsystem, inside the kernel, is not really amenable to be easily used... Regarding the documentation, it will forcefully try to detect asciidoc and, with the latest versions, xmlto, completely disregarding what the user may provide. We currently pass ASCIIDOC= (the empty string) on the make command line, as an attempt to disable building the documentation, but that has no effect whatsoever on perf: that variable is not passed down to the sub-sub-make (yes, a two-level depth) that is responsible for building the documentation. We really do not want to build any of the documentation (the user can refer to the documentation on his own development machine), so we use a little dirty trick: we provide a GNUmakefile beside the existing Makefile for the documentation; GNUmakefile always takes precedence over a Makefile when both are present. We only provide a catch-all-no-recipe rule in that GNUmakefile, so it really does nothing useful, except avoid building the documentation. Signed-off-by: "Yann E. MORIN" Cc: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

perf: append endianness argument to ld when building for MIPS

2016-02-27T17:59:34+00:00

We need to pass an argument to ld for setting the endianness when building it for MIPS architecture, otherwise the default one will always be used (which is big endian) and the compilation for little endian will always fail showing an error like this one: LD foo.o mips-linux-gnu-ld: foo.o: compiled for a little endian system and target is big endian Signed-off-by: Vicente Olivert Riera Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

perf: remove tests from target

2016-01-16T13:04:57+00:00

The perf tool installed test files in output/target/usr/libexec/perf-core/tests/ which amounted to about 30+K. Since they are not needed for normal perf operation, remove them. Signed-off-by: Thomas De Schampheleire Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

package/perf: migrate perf to use the new linux-tools infrastructure

2015-07-14T21:28:06+00:00

Remove the perf package and add legacy handling. [Thomas: - improve the Config.in.legacy help text - improve the comment explaining why we pass O= when building perf] Signed-off-by: Romain Naour Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni