kumquat-buildroot/package/linux-headers/Config.in.host

229 lines
6.3 KiB
Plaintext
Raw Normal View History

comment "Kernel Header Options"
config BR2_PACKAGE_HOST_LINUX_HEADERS
bool
choice
prompt "Kernel Headers"
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL
default BR2_KERNEL_HEADERS_4_9
help
Select the kernel version to get headers from.
The kernel headers must be at least as old as the oldest kernel
you intend to run on your target.
If you use Buildroot to build a kernel, then you can use
the sources from that kernel as source for the headers.
If you choose a custom version of the kernel headers, or choose
to use the same sources as the kernel, you'll have to select
(below) the series of that kernel, so that Buildroot can show
or hide packages that have strong requirements on the kernel
headers.
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
config BR2_KERNEL_HEADERS_AS_KERNEL
bool "Same as kernel being built"
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
depends on BR2_LINUX_KERNEL
config BR2_KERNEL_HEADERS_3_2
bool "Linux 3.2.x kernel headers"
depends on !BR2_arc && !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
config BR2_KERNEL_HEADERS_3_4
bool "Linux 3.4.x kernel headers"
depends on !BR2_arc && !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_4
config BR2_KERNEL_HEADERS_3_10
bool "Linux 3.10.x kernel headers"
depends on !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
config BR2_KERNEL_HEADERS_3_12
bool "Linux 3.12.x kernel headers"
depends on !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
config BR2_KERNEL_HEADERS_3_18
bool "Linux 3.18.x kernel headers"
depends on !BR2_nios2
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18
config BR2_KERNEL_HEADERS_4_1
bool "Linux 4.1.x kernel headers"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_1
config BR2_KERNEL_HEADERS_4_4
bool "Linux 4.4.x kernel headers"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4
config BR2_KERNEL_HEADERS_4_8
bool "Linux 4.8.x kernel headers"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_8
config BR2_KERNEL_HEADERS_4_9
bool "Linux 4.9.x kernel headers"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_9
config BR2_KERNEL_HEADERS_VERSION
bool "Manually specified Linux version"
endchoice
config BR2_DEFAULT_KERNEL_VERSION
string "linux version"
depends on BR2_KERNEL_HEADERS_VERSION
help
Specify the version you want to use.
E.G.: 3.6.10
choice
bool "Custom kernel headers series"
package/linux-headers: add option to use same sources as the kernel Some heavily (and most often improperly) modified Linux kernels may export new APIs to userland, so as to speak to custom hardware or custom kernel facilities. However, we currently have no easy way to use such kernels as a source for the linux-headers package, which precludes having those userland headers intalled for userland applications to use them. We do have a way for the kernel to use the same version as for the headers, but that is definitely not enough, as the linux-headers package has a version choice that is far less versatile and capable than that of the linux package. Add a new option for the linux-headers package, for the user to specify that the version (really, the sources) of the kernel be used to install the headers from. We do that by making linux-headers patch-depend on the linux package. We can't have linux-header simply depend on linux, because the simple dependency means the the dependee will be configured, built and installed before the dependent is configured. And since linux is a target package, it depends on the toolchain, which internally dependes on linux-headers, which would depend on linux, and we'd get a circular dependency. Using patch-depend will ensure that linux is extracted and patched before linux-headers is extracted, which is really all we need. Then, we install the headers from the linux source tree, rather than from linux-headers' source tree (as there's nothing in there!). Since we need to install a private set for uClibc (see cde947f, uclibc: prevent rebuilding after installation to staging), we explicitly set INSTALL_HDR_PATH when calling the kernel' install-headers rule in LINUX_HEADERS_CONFIGURE_CMDS, so that the headers are installed in linux-headers' $(@D) instead of linux' $(@D). Finally, as there is no way to know the kernel version in this case, we must still prompt the user for the kernel series the headers are from (like we do for a custom version) and check for consistency at build time. Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold. [Peter: drop comment as suggested by Thomas] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Karoly Kasza <kaszak@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-20 19:34:28 +01:00
depends on BR2_KERNEL_HEADERS_VERSION || BR2_KERNEL_HEADERS_AS_KERNEL
help
Specify the kernel headers series you manually selected, above.
This is used to hide/show some packages that have strict
requirements on the version of kernel headers.
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9
bool "4.9.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_9
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_8
bool "4.8.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_8
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7
bool "4.7.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_7
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_6
bool "4.6.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_6
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_5
bool "4.5.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_4
bool "4.4.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_3
bool "4.3.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_3
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_2
bool "4.2.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_2
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_1
bool "4.1.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_1
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_0
bool "4.0.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_0
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_19
bool "3.19.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_19
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_18
bool "3.18.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_17
bool "3.17.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_17
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_16
bool "3.16.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_16
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_15
bool "3.15.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_14
bool "3.14.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_13
bool "3.13.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_13
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_12
bool "3.12.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_12
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_11
bool "3.11.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_11
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_10
bool "3.10.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_9
bool "3.9.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_9
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_8
bool "3.8.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_8
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_7
bool "3.7.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_7
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_6
bool "3.6.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_6
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_5
bool "3.5.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_5
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_4
bool "3.4.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_4
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_3
bool "3.3.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_3
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_2
bool "3.2.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_1
bool "3.1.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_1
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_0
bool "3.0.x"
select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0
config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD
bool "2.6.x"
endchoice
config BR2_DEFAULT_KERNEL_HEADERS
string
default "3.2.85" if BR2_KERNEL_HEADERS_3_2
default "3.4.113" if BR2_KERNEL_HEADERS_3_4
default "3.10.105" if BR2_KERNEL_HEADERS_3_10
default "3.12.70" if BR2_KERNEL_HEADERS_3_12
default "3.18.48" if BR2_KERNEL_HEADERS_3_18
default "3.19.8" if BR2_KERNEL_HEADERS_3_19
default "4.0.9" if BR2_KERNEL_HEADERS_4_0
default "4.1.38" if BR2_KERNEL_HEADERS_4_1
default "4.4.52" if BR2_KERNEL_HEADERS_4_4
default "4.8.17" if BR2_KERNEL_HEADERS_4_8
default "4.9.13" if BR2_KERNEL_HEADERS_4_9
default BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION