2015-07-14 19:35:13 +02:00
|
|
|
menu "Linux Kernel Tools"
|
|
|
|
|
|
linux/tools: make it a real, separate package
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.
<builtin>: 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" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
# No prompt, this is sourced by linux/Config.in as this
|
|
|
|
|
# is no real package and really belongs to the kernel.
|
|
|
|
|
config BR2_PACKAGE_LINUX_TOOLS
|
|
|
|
|
bool
|
|
|
|
|
|
2021-07-08 22:15:57 +02:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_BPFTOOL
|
|
|
|
|
bool "bpftool"
|
|
|
|
|
depends on !BR2_nios2 # binutils
|
|
|
|
|
depends on BR2_USE_WCHAR # binutils, elfutils
|
|
|
|
|
depends on !BR2_STATIC_LIBS # elfutils
|
|
|
|
|
depends on BR2_TOOLCHAIN_HAS_THREADS # elfutils
|
|
|
|
|
depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
|
|
|
|
select BR2_PACKAGE_BINUTILS
|
|
|
|
|
select BR2_PACKAGE_ELFUTILS
|
|
|
|
|
help
|
|
|
|
|
bpftool is a tool for for inspection and simple manipulation
|
|
|
|
|
of eBPF programs and maps.
|
|
|
|
|
|
|
|
|
|
These tools are available only from kernel version 4.15.
|
|
|
|
|
|
|
|
|
|
comment "bpftool needs a uClibc or glibc toolchain w/ wchar, dynamic library, threads"
|
|
|
|
|
depends on !BR2_nios2
|
|
|
|
|
depends on !BR2_USE_WCHAR || BR2_STATIC_LIBS \
|
|
|
|
|
|| !BR2_TOOLCHAIN_HAS_THREADS \
|
|
|
|
|
|| !(BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC)
|
|
|
|
|
|
linux/tools: make it a real, separate package
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.
<builtin>: 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" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_CPUPOWER
|
2015-07-14 19:35:13 +02:00
|
|
|
bool "cpupower"
|
linux/tools: make it a real, separate package
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.
<builtin>: 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" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
2015-07-14 19:35:13 +02:00
|
|
|
select BR2_PACKAGE_PCIUTILS
|
|
|
|
|
help
|
|
|
|
|
cpupower is a collection of tools to examine and tune power
|
|
|
|
|
saving related features of your processor.
|
|
|
|
|
|
2016-10-04 18:01:14 +02:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_GPIO
|
|
|
|
|
bool "gpio"
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
|
|
|
|
help
|
|
|
|
|
gpio is a collection of tools to get information about,
|
|
|
|
|
control and monitor gpios present on system.
|
|
|
|
|
|
|
|
|
|
These tools use new gpio ABI which will deprecate sysfs gpio
|
|
|
|
|
interface in the future.
|
|
|
|
|
|
|
|
|
|
These tools are available only from kernel version 4.8.
|
|
|
|
|
|
2016-10-04 18:01:39 +02:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_IIO
|
|
|
|
|
bool "iio"
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
|
|
|
|
help
|
|
|
|
|
iio is a collection of tools to get information about,
|
|
|
|
|
control and monitor iio devices present on system.
|
|
|
|
|
|
|
|
|
|
These tools are available only from kernel version 4.7.
|
|
|
|
|
|
2018-11-13 06:55:53 +01:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_PCI
|
|
|
|
|
bool "pci"
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
|
|
|
|
help
|
|
|
|
|
pcitest is a tool for testing capabilities related to a
|
|
|
|
|
PCI Endpoint (only works with specific Endpoints).
|
|
|
|
|
|
|
|
|
|
These tools are available only from kernel version 4.20.
|
|
|
|
|
|
linux/tools: make it a real, separate package
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.
<builtin>: 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" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_PERF
|
2015-07-14 19:35:14 +02:00
|
|
|
bool "perf"
|
2019-04-18 19:38:45 +02:00
|
|
|
depends on BR2_TOOLCHAIN_HAS_SYNC_4
|
2019-04-22 09:34:24 +02:00
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
2015-07-14 19:35:14 +02:00
|
|
|
help
|
|
|
|
|
perf (sometimes "Perf Events" or perf tools, originally
|
|
|
|
|
"Performance Counters for Linux") - is a performance
|
|
|
|
|
analyzing tool in Linux, available from kernel version
|
|
|
|
|
2.6.31. User-space controlling utility, called 'perf' has
|
|
|
|
|
git-like interface with subcommands. It is capable of
|
|
|
|
|
statistical profiling of entire system (both kernel and user
|
|
|
|
|
code), single CPU or severals threads.
|
|
|
|
|
|
|
|
|
|
This will build and install the userspace 'perf'
|
2018-07-04 09:07:35 +02:00
|
|
|
command.
|
|
|
|
|
|
|
|
|
|
Your kernel must have CONFIG_PERF_EVENTS enabled to use perf
|
|
|
|
|
profiling. Buildroot automatically enables this in the kernel
|
|
|
|
|
configuration.
|
2015-07-14 19:35:14 +02:00
|
|
|
|
|
|
|
|
https://perf.wiki.kernel.org/
|
|
|
|
|
|
2018-04-02 16:02:49 +02:00
|
|
|
if BR2_PACKAGE_LINUX_TOOLS_PERF
|
|
|
|
|
|
|
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_PERF_TUI
|
|
|
|
|
bool "enable perf TUI"
|
|
|
|
|
depends on BR2_USE_MMU # slang
|
|
|
|
|
select BR2_PACKAGE_SLANG
|
|
|
|
|
help
|
|
|
|
|
Enable the TUI interface for perf which requires a TTY and
|
|
|
|
|
enables zooming into DSOs and threads as well as other
|
|
|
|
|
features.
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
linux/tools: make it a real, separate package
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.
<builtin>: 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" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_SELFTESTS
|
2016-03-16 04:26:33 +01:00
|
|
|
bool"selftests"
|
|
|
|
|
depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS # bash
|
|
|
|
|
depends on BR2_USE_MMU # bash
|
2019-10-29 21:40:17 +01:00
|
|
|
depends on !BR2_STATIC_LIBS
|
2021-10-22 23:53:37 +02:00
|
|
|
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14 # util-linux schedutils
|
linux/tools: make it a real, separate package
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.
<builtin>: 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" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
2016-03-16 04:26:33 +01:00
|
|
|
select BR2_PACKAGE_BASH # runtime
|
2019-04-08 18:43:32 +02:00
|
|
|
select BR2_PACKAGE_NCURSES
|
|
|
|
|
select BR2_PACKAGE_NCURSES_TARGET_PROGS # runtime (tput)
|
2019-04-08 18:43:33 +02:00
|
|
|
select BR2_PACKAGE_KMOD
|
|
|
|
|
select BR2_PACKAGE_KMOD_TOOLS # runtime (modprobe -n)
|
2016-03-16 04:26:33 +01:00
|
|
|
select BR2_PACKAGE_POPT
|
|
|
|
|
select BR2_PACKAGE_LIBCAP_NG
|
2019-04-08 18:43:31 +02:00
|
|
|
select BR2_PACKAGE_UTIL_LINUX
|
|
|
|
|
select BR2_PACKAGE_UTIL_LINUX_SCHEDUTILS # runtime (taskset)
|
2016-03-16 04:26:33 +01:00
|
|
|
help
|
|
|
|
|
Build and install (to /usr/lib/kselftests) kernel selftests.
|
|
|
|
|
|
|
|
|
|
Use of this option implies you know the process of using and
|
|
|
|
|
compiling the kernel selftests. The Makefile to build and
|
|
|
|
|
install these is very noisy and may appear to cause your
|
|
|
|
|
build to fail for strange reasons.
|
|
|
|
|
|
|
|
|
|
This is very much a use at your risk option and may not work
|
|
|
|
|
for every setup or every architecture.
|
|
|
|
|
|
2021-10-22 23:53:37 +02:00
|
|
|
comment "selftests needs BR2_PACKAGE_BUSYBOX_SHOW_OTHERS and a toolchain w/ dynamic library and headers >= 3.14"
|
2016-03-16 04:26:33 +01:00
|
|
|
depends on BR2_USE_MMU
|
2021-10-22 23:53:37 +02:00
|
|
|
depends on !BR2_PACKAGE_BUSYBOX_SHOW_OTHERS || \
|
|
|
|
|
BR2_STATIC_LIBS || !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14
|
2016-03-16 04:26:33 +01:00
|
|
|
|
2017-07-19 00:10:31 +02:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_TMON
|
|
|
|
|
bool "tmon"
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
|
|
|
|
select BR2_PACKAGE_NCURSES
|
|
|
|
|
help
|
|
|
|
|
tmon is a terminal-based tool (using curses) that allows the
|
|
|
|
|
user to access thermal information about the system.
|
|
|
|
|
|
package/linux-tools: add hyperv integration services
The hyperv integration services offer convenience features for guest
operating systems running on the microsoft hyperv virtualization
platform. They roughly are for HyperV what openvmtools are for VMWare.
The installed binary names are derived from what seems common in large
distros like RedHat:
linux kernel source name -> installed binary name
hv_vss_daemon -> hypervvssd
hv_kvp_daemon -> hypervkvpd
hv_fcopy_daemon -> hypervfcopyd
Each tool was introduced at different points in the kernel history, so
we need to check each of them.
We provide a single init script that is responsible for starting all
enabled programs. The global status will be the status of the last
program to fail to start, or empty (i.e. success) if they all started
successfuly.
However, we provide one systemd unit per program, because it is not easy
to use a single unit to start (and monitor) more than one executable.
Additionally, we do not provide a template that is filled at tinstall
time either, because it does not gain much (three simple units vs. a
template and some replacement code in the .mk).
Finally, the key-value daemon uses a few helper scripts to get/set the
network config. All are optional (their presence is checked before
running them), but one, hv_set_ifconfig. However, it is not strictly
speaking required either, so we just symlink it to /bin/true to avoid
any warning at runtime. Providing actual helpers is left to the end
user, to adapt to their own environment.
Signed-off-by: Pascal de Bruijn <p.debruijn@unilogic.nl>
[yann.morin.1998@free.fr:
- aggregate all three tools in a single sub-package
- introduce the main HV option, use a sub-option for each tool
- aggregate the three init scripts into one
- don't install the helpers; symlink the mandatory one
- don't create symlinks for systemd units (systemctl preset-all does
it for us now)
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-01-03 20:57:05 +01:00
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_HV
|
|
|
|
|
bool "hv"
|
|
|
|
|
depends on BR2_i386 || BR2_x86_64
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS_HV_KVP_DAEMON if !BR2_PACKAGE_LINUX_TOOLS_HV_HAS_ONE
|
|
|
|
|
help
|
|
|
|
|
Microsoft HyperV integration services
|
|
|
|
|
|
|
|
|
|
Relevant kernel configuration options: CONFIG_HYPERV,
|
|
|
|
|
CONFIG_HYPERV_UTILS.
|
|
|
|
|
|
|
|
|
|
if BR2_PACKAGE_LINUX_TOOLS_HV
|
|
|
|
|
|
|
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_HV_HAS_ONE
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_HV_KVP_DAEMON
|
|
|
|
|
bool "hypervkvpd (hv_kvp_daemon)"
|
|
|
|
|
help
|
|
|
|
|
HyperV uses hypervkvpd (Key/Value Pair daemon) to retrieve
|
|
|
|
|
status information from your virtualized guest OS
|
|
|
|
|
|
|
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_HV_FCOPY_DAEMON
|
|
|
|
|
bool "hypervfcopyd (hv_fcopy_daemon)"
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS_HV_HAS_ONE
|
|
|
|
|
help
|
|
|
|
|
HyperV uses hypervfcopyd (File Copy daemon) to easily transfer
|
|
|
|
|
files to and from your virtualized guest OS
|
|
|
|
|
|
|
|
|
|
config BR2_PACKAGE_LINUX_TOOLS_HV_VSS_DAEMON
|
|
|
|
|
bool "hypervvssd (hv_vss_daemon)"
|
|
|
|
|
select BR2_PACKAGE_LINUX_TOOLS_HV_HAS_ONE
|
|
|
|
|
help
|
|
|
|
|
HyperV uses hypervvssd (Volume Snapshot Service daemon) to
|
|
|
|
|
freeze your filesystems during snapshots and backups
|
|
|
|
|
|
|
|
|
|
endif # BR2_PACKAGE_LINUX_TOOLS_HV
|
|
|
|
|
|
2015-07-14 19:35:13 +02:00
|
|
|
endmenu
|
