Skip to contentSkip to conversation

toolchain: add possibility to use kernel version for linux-headers (branch yem/kenrel-headers)

PATCH New Yann E. MORIN 4 participants 15 messages Jan 20, 2016 – Feb 2, 2016 Arm i.MX and Layerscape

lore
Share & tools
lore

Yann E. MORIN

author
#0 lore raw

cover toolchain: add possibility to use kernel version for linux-headers (branch yem/kenrel-headers)

Hello All!

This small series is a proposal to add the long-awaited-for possibility to use the kernel version as the version for the linux-headers.

- first pach does exactly that,
- second patch changes defconfigs to use it,
- third patch gets rid of the former opposite option.

Regards,
Yann E. MORIN.

The following changes since commit fef4fc0e0ebb5235b4aa9301ee7e34a85e8fb4a3:

libcroco: fix typo in license file (2016-01-20 17:27:25 +0100)

are available in the git repository at:

git://git.busybox.net/~ymorin/git/buildroot yem/kenrel-headers

for you to fetch changes up to f222817257d3ddfbedb60edb0f259ba4ec35e003:

linux: drop the option to use the same version as that of the headers (2016-01-20 19:31:41 +0100)

----------------------------------------------------------------
Yann E. MORIN (3):
package/linux-headers: add option to use same sources as the kernel
defconfigs: use the new headers-version-same-as-kernel-version option
linux: drop the option to use the same version as that of the headers

 Config.in.legacy                         | 10 ++++++++++
 configs/freescale_imx28evk_defconfig     |  5 ++---
 configs/freescale_imx31_3stack_defconfig |  9 ++++-----
 configs/ts5x00_defconfig                 | 15 +++++++++++----
 linux/Config.in                          | 12 ------------
 linux/linux.mk                           |  3 ---
 package/linux-headers/Config.in.host     | 12 +++++++++++-
 package/linux-headers/linux-headers.mk   | 25 ++++++++++++++++++++++---
 8 files changed, 60 insertions(+), 31 deletions(-)
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#1 lore raw

PATCH 1/3 package/linux-headers: add option to use same sources as the kernel

Some heavily (and most often improperly) modified kernel 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 depenency 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.

Signed-off-by "Yann E. MORIN" <[email protected]>
Cc Karoly Kasza <[email protected]>
Cc Thomas Petazzoni <[email protected]>
Cc Peter Korsgaard <[email protected]>
---
 linux/Config.in                        |  1 +
 package/linux-headers/Config.in.host   | 12 +++++++++++-
 package/linux-headers/linux-headers.mk | 25 ++++++++++++++++++++++---
 3 files changed, 34 insertions(+), 4 deletions(-)
linux/Config.in +1 -0
index 263f937..f5865f3 100644
@@ -31,6 +31,7 @@ config BR2_LINUX_KERNEL_LATEST_VERSION
 
 config BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	bool "Same as toolchain kernel headers"
+	depends on !BR2_KERNEL_HEADERS_AS_KERNEL
 	depends on BR2_TOOLCHAIN_BUILDROOT
 	help
 	  This option will re-use the same kernel sources as the one
package/linux-headers/Config.in.host +11 -1
index 41e3a92..a4573d2 100644
@@ -5,12 +5,22 @@ comment "Kernel Header Options"
 
 choice
 	prompt "Kernel Headers"
+	default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL
 	default BR2_KERNEL_HEADERS_4_4
 	help
 	  Select the version of kernel header files you wish to use.
 	  You must select the correct set of header files to match
 	  the kernel you intend to use on your target system.
 
+	config BR2_KERNEL_HEADERS_AS_KERNEL
+		bool "Same as kernel"
+		depends on BR2_LINUX_KERNEL
+
+	comment "Using the same version as that of the"
+		depends on !BR2_LINUX_KERNEL
+	comment "kernel needs a kernel to be built.   "
+		depends on !BR2_LINUX_KERNEL
+
 	config BR2_KERNEL_HEADERS_3_2
 		bool "Linux 3.2.x kernel headers"
 		depends on !BR2_arc && !BR2_nios2

@@ -93,7 +103,7 @@ config BR2_DEFAULT_KERNEL_VERSION
 
 choice
 	bool "Custom kernel headers series"
-	depends on BR2_KERNEL_HEADERS_VERSION
+	depends on BR2_KERNEL_HEADERS_VERSION || BR2_KERNEL_HEADERS_AS_KERNEL
 	default BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD
 	help
 	  Set to the kernel headers series you manually set above.
package/linux-headers/linux-headers.mk +22 -3
index 1b8b81b..6339280 100644
@@ -7,6 +7,19 @@
 # This package is used to provide Linux kernel headers for the
 # internal toolchain backend.
 
+ifeq ($(BR2_KERNEL_HEADERS_AS_KERNEL),y)
+
+LINUX_HEADERS_VERSION = none
+LINUX_HEADERS_SOURCE =
+
+LINUX_HEADERS_LICENSE = $(LINUX_LICENSE)
+LINUX_HEADERS_LICENSE_FILES = $(LINUX_LICENSE_FILES)
+
+LINUX_HEADERS_PATCH_DEPENDENCIES = linux
+LINUX_HEADERS_REAL_DIR = $(LINUX_DIR)
+
+else # ! BR2_KERNEL_HEADERS_AS_KERNEL
+
 LINUX_HEADERS_VERSION = $(call qstrip,$(BR2_DEFAULT_KERNEL_HEADERS))
 ifeq ($(findstring x2.6.,x$(LINUX_HEADERS_VERSION)),x2.6.)
 LINUX_HEADERS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v2.6

@@ -16,9 +29,14 @@ else ifeq ($(findstring x4.,x$(LINUX_HEADERS_VERSION)),x4.)
 LINUX_HEADERS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v4.x
 endif
 LINUX_HEADERS_SOURCE = linux-$(LINUX_HEADERS_VERSION).tar.xz
+
 LINUX_HEADERS_LICENSE = GPLv2
 LINUX_HEADERS_LICENSE_FILES = COPYING
 
+LINUX_HEADERS_REAL_DIR = $(@D)
+
+endif # ! BR2_KERNEL_HEADERS_AS_KERNEL
+
 LINUX_HEADERS_INSTALL_STAGING = YES
 
 # linux-headers is part of the toolchain so disable the toolchain dependency

@@ -35,17 +53,18 @@ LINUX_HEADERS_ADD_TOOLCHAIN_DEPENDENCY = NO
 # uClibc building. This way uClibc doesn't modify linux headers on installation
 # of "its" headers
 define LINUX_HEADERS_CONFIGURE_CMDS
-	(cd $(@D); \
+	(cd $(LINUX_HEADERS_REAL_DIR); \
 		$(TARGET_MAKE_ENV) $(MAKE) \
 			ARCH=$(KERNEL_ARCH) \
 			HOSTCC="$(HOSTCC)" \
 			HOSTCFLAGS="$(HOSTCFLAGS)" \
 			HOSTCXX="$(HOSTCXX)" \
+			INSTALL_HDR_PATH=$(@D)/usr \
 			headers_install)
 endef
 
 define LINUX_HEADERS_INSTALL_STAGING_CMDS
-	(cd $(@D); \
+	(cd $(LINUX_HEADERS_REAL_DIR); \
 		$(TARGET_MAKE_ENV) $(MAKE) \
 			ARCH=$(KERNEL_ARCH) \
 			HOSTCC="$(HOSTCC)" \

@@ -55,7 +74,7 @@ define LINUX_HEADERS_INSTALL_STAGING_CMDS
 			headers_install)
 endef
 
-ifeq ($(BR2_KERNEL_HEADERS_VERSION),y)
+ifeq ($(BR2_KERNEL_HEADERS_VERSION)$(BR2_KERNEL_HEADERS_AS_KERNEL),y)
 define LINUX_HEADERS_CHECK_VERSION
 	$(call check_kernel_headers_version,\
 		$(STAGING_DIR),\
Signature · 1 line
1.9.1
#2 lore raw

PATCH 1/3 package/linux-headers: add option to use same sources as the kernel

Yann,

package/linux-headers/Config.in.host comment "Kernel Header Options" · line 22

Quoted 8 lines · Yann E. MORIN
package/linux-headers/Config.in.host +8 -0
+	config BR2_KERNEL_HEADERS_AS_KERNEL
+		bool "Same as kernel"
+		depends on BR2_LINUX_KERNEL
+
+	comment "Using the same version as that of the"
+		depends on !BR2_LINUX_KERNEL
+	comment "kernel needs a kernel to be built.   "
+		depends on !BR2_LINUX_KERNEL

I think this Config.in comment is useless. It is completely obvious that if you want to re-use the same kernel headers as the kernel you're building, you must have enabled building a kernel with Buildroot.

Other than that, the patch looks good. I haven't tested it, but it looks good.

Yet another feature that would desperately need a test case in our test suite :-)

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#3 lore raw

PATCH 1/3 package/linux-headers: add option to use same sources as the kernel

Thomas, All,

On 2016-01-20 21:36 +0100, Thomas Petazzoni spake thusly:

Quoted 5 lines · Yann E. MORIN
Quoted 4 lines
package/linux-headers/Config.in.host +4 -0
+	config BR2_KERNEL_HEADERS_AS_KERNEL
+		bool "Same as kernel"
+		depends on BR2_LINUX_KERNEL
+
Quoted 8 lines

package/linux-headers/Config.in.host comment "Kernel Header Options" · line 22

Quoted 4 lines
package/linux-headers/Config.in.host +4 -0
+	comment "Using the same version as that of the"
+		depends on !BR2_LINUX_KERNEL
+	comment "kernel needs a kernel to be built.   "
+		depends on !BR2_LINUX_KERNEL

I think this Config.in comment is useless. It is completely obvious that if you want to re-use the same kernel headers as the kernel you're building, you must have enabled building a kernel with Buildroot.

Yeah, I knew it was redundant; I'll remove it.

Quoted 5 lines

Other than that, the patch looks good. I haven't tested it, but it looks good.

Yet another feature that would desperately need a test case in our test suite :-)

Hehe! :-)

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#4 lore raw

PATCH 1/3 package/linux-headers: add option to use same sources as the kernel

In reply to Yann E. MORIN
Quoted 44 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Yann" == Yann E MORIN <[email protected]> writes:

Some heavily (and most often improperly) modified kernel 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 depenency 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.

Quoted 7 lines

Note however that this still leaves users that want to built their such-kernel outside of Buildroot out in the cold.

Signed-off-by "Yann E. MORIN" <[email protected]>
Cc Karoly Kasza <[email protected]>
Cc Thomas Petazzoni <[email protected]>
Cc Peter Korsgaard <[email protected]>

Committed after dropping the comment as suggested by Thomas, thanks.

Signature · 1 line
Bye, Peter Korsgaard
author
#5 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

In reply to Yann E. MORIN

Now that we can say that the linux headers version should match that of the kernel to be built, we inverse the logic in our defconfigs, as it is more sensible that way.

And also because we'll get rid of the former, converse kernel-same-as-headers option.

Signed-off-by "Yann E. MORIN" <[email protected]>
---
 configs/freescale_imx28evk_defconfig     |  5 ++---
 configs/freescale_imx31_3stack_defconfig |  9 ++++-----
 configs/ts5x00_defconfig                 | 15 +++++++++++----
 3 files changed, 17 insertions(+), 12 deletions(-)
configs/freescale_imx28evk_defconfig +2 -3
index 9ce5217..3f2f9e7 100644
@@ -3,8 +3,6 @@ BR2_arm=y
 BR2_arm926t=y
 
 # toolchain
-BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.19.2"
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_19=y
 
 # system

@@ -12,7 +10,8 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
 
 # kernel
 BR2_LINUX_KERNEL=y
-BR2_LINUX_KERNEL_SAME_AS_HEADERS=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.19.2"
 BR2_LINUX_KERNEL_DEFCONFIG="mxs"
 BR2_LINUX_KERNEL_ZIMAGE=y
 BR2_LINUX_KERNEL_DTS_SUPPORT=y
configs/freescale_imx31_3stack_defconfig +4 -5
index 68781eb..ded6563 100644
@@ -4,10 +4,6 @@ BR2_arm1136jf_s_r0=y
 BR2_ARM_EABIHF=y
 
 # toolchain
-BR2_KERNEL_HEADERS_VERSION=y
-# Note: sadly the Linux kernel will not boot on the i.MX31 PDK, starting with
-# v3.16 and at least up to v4.0-rc4; this is why we use v3.15.y here.
-BR2_DEFAULT_KERNEL_VERSION="3.15.10"
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_15=y
 
 # system

@@ -15,7 +11,10 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttymxc0"
 
 # kernel
 BR2_LINUX_KERNEL=y
-BR2_LINUX_KERNEL_SAME_AS_HEADERS=y
+# Note: sadly the Linux kernel will not boot on the i.MX31 PDK, starting with
+# v3.16 and at least up to v4.0-rc4; this is why we use v3.15.y here.
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.15.10"
 BR2_LINUX_KERNEL_DEFCONFIG="imx_v6_v7"
 BR2_LINUX_KERNEL_ZIMAGE=y
 BR2_TARGET_ROOTFS_CPIO_GZIP=y
configs/ts5x00_defconfig +11 -4
index befb655..6f140e6 100644
@@ -1,19 +1,26 @@
+# architecture
 BR2_i386=y
 BR2_x86_i586=y
 
-# Lock headers version to match and avoid breakage
-BR2_KERNEL_HEADERS_VERSION=y
-BR2_DEFAULT_KERNEL_VERSION="3.17.8"
+# toolchain
 BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_17=y
 
+# system
 BR2_TARGET_GENERIC_GETTY_PORT="ttyS1"
 BR2_ROOTFS_OVERLAY="board/ts/ts5x00/fs-overlay"
+
+# kernel
 BR2_LINUX_KERNEL=y
-BR2_LINUX_KERNEL_SAME_AS_HEADERS=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.17.8"
 BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
 BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/ts/ts5x00/linux-3.17.config"
 BR2_LINUX_KERNEL_INSTALL_TARGET=y
+
+# rootfs
 BR2_TARGET_ROOTFS_EXT2=y
 BR2_TARGET_ROOTFS_EXT2_4=y
+
+# bootloader
 BR2_TARGET_SYSLINUX=y
 BR2_TARGET_SYSLINUX_MBR=y
Signature · 1 line
1.9.1
#6 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

Dear Yann E. MORIN,

Quoted 8 lines · Yann E. MORIN

Now that we can say that the linux headers version should match that of the kernel to be built, we inverse the logic in our defconfigs, as it is more sensible that way.

And also because we'll get rid of the former, converse kernel-same-as-headers option.

Signed-off-by "Yann E. MORIN" <[email protected]>

In this commit, you are changing the defconfigs that use BR2_LINUX_KERNEL_SAME_AS_HEADERS. But I am wondering if we shouldn't simply change *all* defconfigs to use this new feature. Essentially all defconfigs have to worry about selecting a kernel headers version that matches the kernel version they use. We could switch them all to use your new mechanism, no?

Of course, this can be done as a separate effort, this is not a call to change this particular patch, but rather a discussion on what to do next.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#7 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

Quoted 20 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Dear Yann E. MORIN,

Quoted 8 lines · Yann E. MORIN

Now that we can say that the linux headers version should match that of the kernel to be built, we inverse the logic in our defconfigs, as it is more sensible that way.

And also because we'll get rid of the former, converse kernel-same-as-headers option.

Signed-off-by "Yann E. MORIN" <[email protected]>

In this commit, you are changing the defconfigs that use BR2_LINUX_KERNEL_SAME_AS_HEADERS. But I am wondering if we shouldn't simply change *all* defconfigs to use this new feature. Essentially all defconfigs have to worry about selecting a kernel headers version that matches the kernel version they use. We could switch them all to use your new mechanism, no?

Quoted 3 lines

Of course, this can be done as a separate effort, this is not a call to change this particular patch, but rather a discussion on what to do next.

Agreed. As long as we use the internal toolchain for our defconfigs and build a kernel (and we so far always do), it makes sense to use this option.

Signature · 1 line
Bye, Peter Korsgaard
#8 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

Can we still have different header and kernel versions?

As I understand it we have to rebuild the toolchain when we change header versions. So if I have a working embedded system based on kernel x and am trying to get a new one working with kernel x+1, I really don't want to change the kernel header version. In this case they should be backward compatible. And rebuilding the toolchain is such a pain that I always use an external toolchain, even if using the buildroot internal built one.

So as long as I can still have separate header/kernel versions, I am happy with this change. Otherwise, it will be a pain with more full rebuilds.

Regards, Steve

#9 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

Dear Steve Calfee,

Quoted 10 lines · Steve Calfee

Can we still have different header and kernel versions?

As I understand it we have to rebuild the toolchain when we change header versions. So if I have a working embedded system based on kernel x and am trying to get a new one working with kernel x+1, I really don't want to change the kernel header version. In this case they should be backward compatible. And rebuilding the toolchain is such a pain that I always use an external toolchain, even if using the buildroot internal built one.

Quoted 3 lines

So as long as I can still have separate header/kernel versions, I am happy with this change. Otherwise, it will be a pain with more full rebuilds.

What Yann is adding is just another option to choose the kernel headers version. The other options (to use 4.4, a custom version, etc.) remain in place.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#10 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

In reply to Steve Calfee

Steve, All,

On 2016-01-20 13:37 -0800, Steve Calfee spake thusly:

Quoted 1 line

Can we still have different header and kernel versions?

Yes! :-)

Quoted 7 lines

As I understand it we have to rebuild the toolchain when we change header versions. So if I have a working embedded system based on kernel x and am trying to get a new one working with kernel x+1, I really don't want to change the kernel header version. In this case they should be backward compatible. And rebuilding the toolchain is such a pain that I always use an external toolchain, even if using the buildroot internal built one.

When you use an external toolchain, you can't use this new same-version-as-for-kernel option, since it is only available for the internal toolchain.

For the external toolchain (even if built by Buildroot), you anyway have to tell what the kernel series the headers are from.

Quoted 3 lines

So as long as I can still have separate header/kernel versions, I am happy with this change. Otherwise, it will be a pain with more full rebuilds.

No, it is just another option.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#11 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

In reply to Thomas Petazzoni

Thomas, All,

On 2016-01-20 21:38 +0100, Thomas Petazzoni spake thusly:

Quoted 8 lines · Yann E. MORIN
Quoted 7 lines

Now that we can say that the linux headers version should match that of the kernel to be built, we inverse the logic in our defconfigs, as it is more sensible that way.

And also because we'll get rid of the former, converse kernel-same-as-headers option.

Quoted 8 lines
Quoted 1 line
Signed-off-by "Yann E. MORIN" <[email protected]>

In this commit, you are changing the defconfigs that use BR2_LINUX_KERNEL_SAME_AS_HEADERS. But I am wondering if we shouldn't simply change *all* defconfigs to use this new feature. Essentially all defconfigs have to worry about selecting a kernel headers version that matches the kernel version they use. We could switch them all to use your new mechanism, no?

Well, I think it may be worse than that, in fact... Let's see what happens with a trivial defconfig from before this patch, with the default toolchain and the kernel settings:

BR2_LINUX_KERNEL=y

This would give:

    BR2_KERNEL_HEADERS_4_4=y
    BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y
    BR2_TOOLCHAIN_HEADERS_AT_LEAST="4.4"
    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_LATEST_VERSION=y

Now we use that defconfig after this patch, this gives:

    BR2_KERNEL_HEADERS_AS_KERNEL=y
    BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD=y
    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_VERSION="4.4"

And boom, we've lost BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y

I have no idea how we could solve this. I doubt we want to add anything like BR2_LINUX_KERNEL_AT_LEAST_4_4 and the likes... :-/

Ideas?

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#12 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

Hello,

Quoted 21 lines · Yann E. MORIN

Well, I think it may be worse than that, in fact... Let's see what happens with a trivial defconfig from before this patch, with the default toolchain and the kernel settings:

BR2_LINUX_KERNEL=y

This would give:

    BR2_KERNEL_HEADERS_4_4=y
    BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y
    BR2_TOOLCHAIN_HEADERS_AT_LEAST="4.4"
    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_LATEST_VERSION=y

Now we use that defconfig after this patch, this gives:

    BR2_KERNEL_HEADERS_AS_KERNEL=y
    BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD=y
    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_VERSION="4.4"
Quoted 6 lines

And boom, we've lost BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y

I have no idea how we could solve this. I doubt we want to add anything like BR2_LINUX_KERNEL_AT_LEAST_4_4 and the likes... :-/

Ideas?

Remove:

default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL

?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#13 lore raw

PATCH 2/3 defconfigs: use the new headers-version-same-as-kernel-version option

Thomas, All,

On 2016-01-20 23:07 +0100, Thomas Petazzoni spake thusly:

Quoted 24 lines · Yann E. MORIN
Quoted 23 lines

Well, I think it may be worse than that, in fact... Let's see what happens with a trivial defconfig from before this patch, with the default toolchain and the kernel settings:

BR2_LINUX_KERNEL=y

This would give:

    BR2_KERNEL_HEADERS_4_4=y
    BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y
    BR2_TOOLCHAIN_HEADERS_AT_LEAST="4.4"
    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_LATEST_VERSION=y

Now we use that defconfig after this patch, this gives:

    BR2_KERNEL_HEADERS_AS_KERNEL=y
    BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD=y
    BR2_LINUX_KERNEL=y
    BR2_LINUX_KERNEL_VERSION="4.4"

And boom, we've lost BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y

Quoted 8 lines
Quoted 4 lines

I have no idea how we could solve this. I doubt we want to add anything like BR2_LINUX_KERNEL_AT_LEAST_4_4 and the likes... :-/

Ideas?

Remove:
default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL
?

Indeed. :-)

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#14 lore raw

PATCH 3/3 linux: drop the option to use the same version as that of the headers

In reply to Yann E. MORIN

It is no longer meaningful, now that we have the option to use the kernel version for the linux headers, as it is more logical and more versatile.

Add it to legacy.

Signed-off-by "Yann E. MORIN" <[email protected]>
---
 Config.in.legacy | 10 ++++++++++
 linux/Config.in  | 13 -------------
 linux/linux.mk   |  3 ---
 3 files changed, 10 insertions(+), 16 deletions(-)
Config.in.legacy +10 -0
index 2e6062c..2476b1a 100644
@@ -145,6 +145,16 @@ endif
 ###############################################################################
 comment "Legacy options removed in 2016.02"
 
+config BR2_LINUX_KERNEL_SAME_AS_HEADERS
+	bool "using the linux headers version for the kernel has been removed"
+	select BR2_LEGACY
+	help
+	  The option to use the version of the kernel headers for the
+	  kernel to build has been removed.
+
+	  There is now the converse, better-suited and more versatile
+	  option to use the kernel version for the linux headers.
+
 config BR2_PACKAGE_PYTHON_PYXML
 	bool "python-pyxml package has been removed"
 	select BR2_LEGACY
linux/Config.in +0 -13
index f5865f3..386e1d7 100644
@@ -29,18 +29,6 @@ choice
 config BR2_LINUX_KERNEL_LATEST_VERSION
 	bool "4.4"
 
-config BR2_LINUX_KERNEL_SAME_AS_HEADERS
-	bool "Same as toolchain kernel headers"
-	depends on !BR2_KERNEL_HEADERS_AS_KERNEL
-	depends on BR2_TOOLCHAIN_BUILDROOT
-	help
-	  This option will re-use the same kernel sources as the one
-	  that have been used for the kernel headers of the
-	  cross-compiling toolchain. Having the same version for the
-	  kernel running on the system and for the kernel headers is
-	  not a requirement, but using the same version allows to
-	  download only one tarball of the kernel sources.
-
 config BR2_LINUX_KERNEL_CUSTOM_VERSION
 	bool "Custom version"
 	help

@@ -117,7 +105,6 @@ config BR2_LINUX_KERNEL_CUSTOM_LOCAL_PATH
 config BR2_LINUX_KERNEL_VERSION
 	string
 	default "4.4" if BR2_LINUX_KERNEL_LATEST_VERSION
-	default BR2_DEFAULT_KERNEL_HEADERS if BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE \
 		if BR2_LINUX_KERNEL_CUSTOM_VERSION
 	default "custom" if BR2_LINUX_KERNEL_CUSTOM_TARBALL
linux/linux.mk +0 -3
index 3c53a0b..936d68d 100644
@@ -28,9 +28,6 @@ LINUX_SOURCE = linux-$(LINUX_VERSION).tar.xz
 ifeq ($(BR2_LINUX_KERNEL_CUSTOM_VERSION),y)
 BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
 endif
-ifeq ($(BR2_LINUX_KERNEL_SAME_AS_HEADERS)$(BR2_KERNEL_HEADERS_VERSION),yy)
-BR_NO_CHECK_HASH_FOR += $(LINUX_SOURCE)
-endif
 # In X.Y.Z, get X and Y. We replace dots and dashes by spaces in order
 # to use the $(word) function. We support versions such as 4.0, 3.1,
 # 2.6.32, 2.6.32-rc1, 3.0-rc6, etc.
Signature · 1 line
1.9.1