[Buildroot] [PATCH 0/3] toolchain: add possibility to use kernel version for linux-headers (branch yem/kenrel-headers)

[Buildroot] [PATCH 0/3] toolchain: add possibility to use kernel version for linux-headers (branch yem/kenrel-headers)

[Yann E. MORIN]

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(-)

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Yann E. MORIN]

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" <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>
---
 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(-)

diff --git a/linux/Config.in b/linux/Config.in
index 263f937..f5865f3 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -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
diff --git a/package/linux-headers/Config.in.host b/package/linux-headers/Config.in.host
index 41e3a92..a4573d2 100644
--- a/package/linux-headers/Config.in.host
+++ b/package/linux-headers/Config.in.host
@@ -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.
diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk
index 1b8b81b..6339280 100644
--- a/package/linux-headers/linux-headers.mk
+++ b/package/linux-headers/linux-headers.mk
@@ -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),\
-- 
1.9.1

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

[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" <yann.morin.1998@free.fr>
---
 configs/freescale_imx28evk_defconfig     |  5 ++---
 configs/freescale_imx31_3stack_defconfig |  9 ++++-----
 configs/ts5x00_defconfig                 | 15 +++++++++++----
 3 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/configs/freescale_imx28evk_defconfig b/configs/freescale_imx28evk_defconfig
index 9ce5217..3f2f9e7 100644
--- a/configs/freescale_imx28evk_defconfig
+++ b/configs/freescale_imx28evk_defconfig
@@ -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
diff --git a/configs/freescale_imx31_3stack_defconfig b/configs/freescale_imx31_3stack_defconfig
index 68781eb..ded6563 100644
--- a/configs/freescale_imx31_3stack_defconfig
+++ b/configs/freescale_imx31_3stack_defconfig
@@ -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
diff --git a/configs/ts5x00_defconfig b/configs/ts5x00_defconfig
index befb655..6f140e6 100644
--- a/configs/ts5x00_defconfig
+++ b/configs/ts5x00_defconfig
@@ -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
-- 
1.9.1

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

[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" <yann.morin.1998@free.fr>
---
 Config.in.legacy | 10 ++++++++++
 linux/Config.in  | 13 -------------
 linux/linux.mk   |  3 ---
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
index 2e6062c..2476b1a 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -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
diff --git a/linux/Config.in b/linux/Config.in
index f5865f3..386e1d7 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -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
diff --git a/linux/linux.mk b/linux/linux.mk
index 3c53a0b..936d68d 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -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.
-- 
1.9.1

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

[Thomas Petazzoni]

Yann,

On Wed, 20 Jan 2016 19:34:28 +0100, Yann E. MORIN wrote:

> +	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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Wed, 20 Jan 2016 19:34:29 +0100, Yann E. MORIN wrote:
> 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" <yann.morin.1998@free.fr>

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Yann E. MORIN]

Thomas, All,

On 2016-01-20 21:36 +0100, Thomas Petazzoni spake thusly:
> On Wed, 20 Jan 2016 19:34:28 +0100, Yann E. MORIN wrote:
> > +	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.

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

> 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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Dear Yann E. MORIN,
 > On Wed, 20 Jan 2016 19:34:29 +0100, Yann E. MORIN wrote:
 >> 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" <yann.morin.1998@free.fr>

 > 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.

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.

-- 
Bye, Peter Korsgaard

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

[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.

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

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

[Yann E. MORIN]

Thomas, All,

On 2016-01-20 21:38 +0100, Thomas Petazzoni spake thusly:
> On Wed, 20 Jan 2016 19:34:29 +0100, Yann E. MORIN wrote:
> > 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" <yann.morin.1998@free.fr>
> 
> 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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Thomas Petazzoni]

Dear Steve Calfee,

On Wed, 20 Jan 2016 13:37:56 -0800, Steve Calfee wrote:
> 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.

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Thomas Petazzoni]

Hello,

On Wed, 20 Jan 2016 22:58:21 +0100, Yann E. MORIN wrote:

> 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?

Remove:

	default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL

 ?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Yann E. MORIN]

Steve, All,

On 2016-01-20 13:37 -0800, Steve Calfee spake thusly:
> Can we still have different header and kernel versions?

Yes! :-)

> 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.

> 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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Yann E. MORIN]

Thomas, All,

On 2016-01-20 23:07 +0100, Thomas Petazzoni spake thusly:
> On Wed, 20 Jan 2016 22:58:21 +0100, Yann E. MORIN wrote:
> > 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?
> 
> Remove:
> 	default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL
>  ?

Indeed. :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> 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.

 > 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" <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>

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

-- 
Bye, Peter Korsgaard