linux-headers: allow use of headers from kernel "package" selected

PATCH New Karoly Kasza 6 participants 21 messages Mar 1, 2015 – Jan 19, 2016

Share & tools

Karoly Kasza

author

2015-03-01 17:17 UTC #0 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

This change makes it possible to use exactly the same sources for both headers during toolchain building and for kernel building itself, even if custom kernel is selected.

That way users can be sure that ABI mismatch won't happen between toolchain and kernel.

Signed-off-by Karoly Kasza <[email protected]>

---

Changes v3 -> v4:
- Rebased to cleanly apply again

 linux/Config.in                        |    1 +
 linux/linux.mk                         |    7 +++++++
 package/linux-headers/Config.in.host   |   14 ++++++++++++--
 package/linux-headers/linux-headers.mk |    9 +++++++++
 4 files changed, 29 insertions(+), 2 deletions(-)

linux/Config.in +1 -0

index c981493..30faaaf 100644
@@ -26,6 +26,7 @@ config BR2_LINUX_KERNEL_LATEST_VERSION
 config BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	bool "Same as toolchain kernel headers"
 	depends on BR2_TOOLCHAIN_BUILDROOT
+	depends on !BR2_KERNEL_HEADERS_SAME_AS_KERNEL
 	help
 	  This option will re-use the same kernel sources as the one
 	  that have been used for the kernel headers of the

linux/linux.mk +7 -0

index 0b8c912..29d93db 100644
@@ -8,6 +8,9 @@ LINUX_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
 LINUX_LICENSE = GPLv2
 LINUX_LICENSE_FILES = COPYING
 
+# Compute variables as a function, so linux-headers can call it when needed
+define BR2_LINUX_COMPUTE_VARS
+
 # Compute LINUX_SOURCE and LINUX_SITE from the configuration
 ifeq ($(BR2_LINUX_KERNEL_CUSTOM_TARBALL),y)
 LINUX_TARBALL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION))

@@ -40,6 +43,10 @@ LINUX_SITE := $(LINUX_SITE)/testing/
 endif # -rc
 endif
 
+endef
+
+$(eval $(BR2_LINUX_COMPUTE_VARS))
+
 LINUX_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH))
 
 LINUX_INSTALL_IMAGES = YES

package/linux-headers/Config.in.host +12 -2

index 2755f2f..7a06224 100644
@@ -5,6 +5,7 @@ comment "Kernel Header Options"
 
 choice
 	prompt "Kernel Headers"
+	default BR2_KERNEL_HEADERS_SAME_AS_KERNEL if BR2_LINUX_KERNEL
 	default BR2_KERNEL_HEADERS_3_18
 	help
 	  Select the version of kernel header files you wish to use.

@@ -69,6 +70,13 @@ choice
 
 	config BR2_KERNEL_HEADERS_VERSION
 		bool "Manually specified Linux version"
+
+	config BR2_KERNEL_HEADERS_SAME_AS_KERNEL
+		bool "Use Linux kernel specified for target"
+		depends on BR2_LINUX_KERNEL
+		help
+		  Use the Linux kernel specified for the target in
+		  the Kernel menu.
 endchoice
 
 config BR2_DEFAULT_KERNEL_VERSION

@@ -80,10 +88,12 @@ 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_SAME_AS_KERNEL
 	default BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD
 	help
-	  Set to the kernel headers series you manually set above.
+	  Set to the kernel headers series you manually entered in
+	  "linux version" field or matching version of specific kernel selected
+	  for building in "kernel" section.
 
 	  This is used to hide/show some packages that have strict
 	  requirements on the version of kernel headers.

package/linux-headers/linux-headers.mk +9 -0

index d770927..b4a1c8d 100644
@@ -7,6 +7,14 @@
 # This package is used to provide Linux kernel headers for the
 # internal toolchain backend.
 
+ifeq ($(BR2_KERNEL_HEADERS_SAME_AS_KERNEL),y)
+# Force computing the variables from the Kernel package
+$(eval $(BR2_LINUX_COMPUTE_VARS))
+LINUX_HEADERS_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
+LINUX_HEADERS_SOURCE = $(LINUX_SOURCE)
+LINUX_HEADERS_SITE = $(LINUX_SITE)
+LINUX_HEADERS_SITE_METHOD = $(LINUX_SITE_METHOD)
+else
 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

@@ -14,6 +22,7 @@ else
 LINUX_HEADERS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v3.x
 endif
 LINUX_HEADERS_SOURCE = linux-$(LINUX_HEADERS_VERSION).tar.xz
+endif
 
 LINUX_HEADERS_INSTALL_STAGING = YES

Signature · 1 line

1.7.10.4

Thomas Petazzoni

2015-03-04 22:37 UTC #1 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Dear Karoly Kasza,

Quoted 15 lines · Karoly Kasza

linux/linux.mk +3 -0

index 0b8c912..29d93db 100644
@@ -8,6 +8,9 @@ LINUX_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
 LINUX_LICENSE = GPLv2
 LINUX_LICENSE_FILES = COPYING
 
+# Compute variables as a function, so linux-headers can call it when needed
+define BR2_LINUX_COMPUTE_VARS
+
 # Compute LINUX_SOURCE and LINUX_SITE from the configuration
 ifeq ($(BR2_LINUX_KERNEL_CUSTOM_TARBALL),y)
 LINUX_TARBALL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION))

linux/linux.mk LINUX_SITE := $(LINUX_SITE)/testing/ · line 48

Quoted 6 lines

linux/linux.mk +3 -0

@@ -40,6 +43,10 @@ LINUX_SITE := $(LINUX_SITE)/testing/
 endif # -rc
 endif
 
+endef
+
+$(eval $(BR2_LINUX_COMPUTE_VARS))

I know this is not going to be a very useful answer, but I must say I don't really like this <foo>_COMPUTE_VARS solution :-/

I unfortunately don't have many solutions to offer to solve this problem.

Thomas

Signature · 3 lines

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

Алексей Бродкин

2015-03-12 14:07 UTC #2 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Hi Thomas,

2015-03-05 1:37 GMT+03:00 Thomas Petazzoni
<[email protected]>:

Quoted 28 lines

Dear Karoly Kasza,
Quoted 15 lines · Karoly Kasza
linux/linux.mk +3 -0
index 0b8c912..29d93db 100644
@@ -8,6 +8,9 @@ LINUX_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
 LINUX_LICENSE = GPLv2
 LINUX_LICENSE_FILES = COPYING
 
+# Compute variables as a function, so linux-headers can call it when needed
+define BR2_LINUX_COMPUTE_VARS
+
 # Compute LINUX_SOURCE and LINUX_SITE from the configuration
 ifeq ($(BR2_LINUX_KERNEL_CUSTOM_TARBALL),y)
 LINUX_TARBALL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION))
linux/linux.mk LINUX_SITE := $(LINUX_SITE)/testing/ · line 48
Quoted 6 lines
linux/linux.mk +3 -0
@@ -40,6 +43,10 @@ LINUX_SITE := $(LINUX_SITE)/testing/
 endif # -rc
 endif
 
+endef
+
+$(eval $(BR2_LINUX_COMPUTE_VARS))
I know this is not going to be a very useful answer, but I must say I don't really like this <foo>_COMPUTE_VARS solution :-/

Quoted 2 lines

I unfortunately don't have many solutions to offer to solve this problem.

But why not? I mean this change looks very small and clean, it doesn't introduce a lot of code and new unclear logic.

As long as it works I'm all for getting it applied finally.

I do understand that this is rarely needed functionality because ABI changes not that often (and ABI is the only reason we need headers), but I may understand corner-cases especially during kernel development and especially on upstreaming process that we [ARC] were recently through.

There was a period of time we had 3 ABIs in use. If of any interest please refer to this article -
https://github.com/foss-for-synopsys-dwc-arc-processors/linux/wiki/ARC-Linux-Syscall-ABI-Compatibility

So you may imagine how helpful it could be to have proposed option in some situations :)

-Alexey

Yann E. MORIN

2016-01-09 17:29 UTC #3 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

In reply to Karoly Kasza

Karoly, All,

Reviving this old one that is still pending in Patchwork...

On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:

Quoted 6 lines

This change makes it possible to use exactly the same sources for both headers during toolchain building and for kernel building itself, even if custom kernel is selected.
That way users can be sure that ABI mismatch won't happen between toolchain and kernel.

So, I'll try to summarise what we have for now:

- select kernel headers version and select kernel version (separately)

- select kernel headers version, also used as kernel version.

What you want to add with this patch is:

- select kernel version, also used as kernel headers version.

In fact, I think that the second case we already have (headers version implies kernel version) is a bit weird. Surely, I would have expected something reversed, like "kernel version implies headers version", which this patch is trying to provide.

So, it just occured to me, that the second case we already have for now is not really what we need because it does not rally make sense. What we need as it makes more sense is the reverse of what we currently have.

So, I've had a little look, and I think we may have a solution to this version string mess.

In Kconfig, one can default a string option to either a constant, or to another variable, like:

config FOO
string "foo"

config BAR
string
default FOO

In this case, BAR will have the same value as set for FOO. It also works if FOO has no prompt and only gets its value from (conditional) defaults, like:

choice
bool "Version?"
config A1
bool "A1"
config A2
bool "A2"
endchoice

config VERSION
string
default "A1" if A1
default "A2" if A2

config VER
string
default VERSION

So, at first sight, we could still have the option handled from kconfig, whereby the kernel headers version would be set like so from the kernel version.

In the end, to summarise:
1) we remove the current "headers version implies kernel version" possibility (beware to handle legacy)
2) we add the "kernel version implies headers version" possibility, setting the headers version from kconfig.

Thomas, what's your opinion?

Karoly, are you still interested in this feature? If so, are you willing to look at the above proposal of mine, and see if you can get something usefull out of it? ;-)

Thanks!

In the meantime, I'm marking this patch as "changes requested" in our patchwork.

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

Peter Korsgaard

2016-01-18 09:21 UTC #4 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Quoted 19 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Karoly, All,
Reviving this old one that is still pending in Patchwork...
On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
Quoted 6 lines
This change makes it possible to use exactly the same sources for both headers during toolchain building and for kernel building itself, even if custom kernel is selected.
That way users can be sure that ABI mismatch won't happen between toolchain and kernel.
So, I'll try to summarise what we have for now:
- select kernel headers version and select kernel version (separately)
- select kernel headers version, also used as kernel version.

Quoted 8 lines

What you want to add with this patch is:
- select kernel version, also used as kernel headers version.
In fact, I think that the second case we already have (headers version implies kernel version) is a bit weird. Surely, I would have expected something reversed, like "kernel version implies headers version", which this patch is trying to provide.

I think part of the reason we have it this way is purely historical (E.G. we had support for building a toolchain a lot earlier than we had a generic way of building a Linux kernel, and for a long time we would always build an internal toolchain, but building a kernel is optional), but also because the kernel headers option comes before the Linux option, so you would need to go and enable the Linux kernel and then go back and change the kernel headers option.

The question is also what do about the kernel headers option if you go and disable building a Linux kernel?

Perhaps we can find good solutions to these questions, but all in all, I'm not sure it is worth it. What we have today is functionally equivalent, even though it is perhaps a bit backwards for certain use cases.

Signature · 1 line

Bye, Peter Korsgaard

Yann E. MORIN

2016-01-18 21:47 UTC #5 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Peter, Karoly, All,

On 2016-01-18 10:21 +0100, Peter Korsgaard spake thusly:

Quoted 23 lines

Quoted 13 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Karoly, All,
Reviving this old one that is still pending in Patchwork...
On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
Quoted 6 lines
This change makes it possible to use exactly the same sources for both headers during toolchain building and for kernel building itself, even if custom kernel is selected.
That way users can be sure that ABI mismatch won't happen between toolchain and kernel.
Quoted 9 lines
So, I'll try to summarise what we have for now:
- select kernel headers version and select kernel version (separately)
- select kernel headers version, also used as kernel version.
What you want to add with this patch is:
- select kernel version, also used as kernel headers version.
In fact, I think that the second case we already have (headers version implies kernel version) is a bit weird. Surely, I would have expected something reversed, like "kernel version implies headers version", which this patch is trying to provide.

Quoted 1 line

I think part of the reason we have it this way is purely historical

Yes, it is purely historical.

Quoted 6 lines

(E.G. we had support for building a toolchain a lot earlier than we had a generic way of building a Linux kernel, and for a long time we would always build an internal toolchain, but building a kernel is optional), but also because the kernel headers option comes before the Linux option, so you would need to go and enable the Linux kernel and then go back and change the kernel headers option.

Indeed, it does not seem like it would be very user-friendly... :-/

Quoted 7 lines

The question is also what do about the kernel headers option if you go and disable building a Linux kernel?
Perhaps we can find good solutions to these questions, but all in all, I'm not sure it is worth it. What we have today is functionally equivalent, even though it is perhaps a bit backwards for certain use cases.

Yes, it *is* functionally equivalent. It just looks weird that you have to define the kernel version after (as 'as a conseuence of) the headers version, since logically, it is the opposite that one would want.

However, as you said, it would not be very practical to implement that in a user-friendly way:
- on one hand, it seems totally more logical to define the toolchain options before enblign a kernel,
- on the other hand, the kernel headers version is very dependent on the running kernel version.

Chicken'n'egg problem... :-(

So, do we agree that we should drop this patch?

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

Peter Korsgaard

2016-01-18 21:50 UTC #6 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Quoted 1 line

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

Hi,

Quoted 3 lines

Chicken'n'egg problem... :-(
So, do we agree that we should drop this patch?

That's my opinion atleast. Anyone else against it?

Signature · 2 lines

Venlig hilsen,
Peter Korsgaard

Thomas Petazzoni

2016-01-18 22:03 UTC #7 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

In reply to Yann E. MORIN

Yann,

Quoted 11 lines · Yann E. MORIN

Yes, it *is* functionally equivalent. It just looks weird that you have to define the kernel version after (as 'as a conseuence of) the headers version, since logically, it is the opposite that one would want.
However, as you said, it would not be very practical to implement that in a user-friendly way:
- on one hand, it seems totally more logical to define the toolchain options before enblign a kernel,
- on the other hand, the kernel headers version is very dependent on the running kernel version.

Quoted 3 lines

Chicken'n'egg problem... :-(
So, do we agree that we should drop this patch?

I also don't like the way the patch is implemented, but I think the problem raised by this patch is real. Sometimes people have kernel sources that contain some custom kernel headers needed for their userspace libraries/applications, and we have no mechanism to allow them to use their custom kernel source for the linux-headers package, which is a bit annoying.

Best regards,

Thomas

Signature · 3 lines

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

Yann E. MORIN

2016-01-18 22:13 UTC #8 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Thomas, All,

On 2016-01-18 23:03 +0100, Thomas Petazzoni spake thusly:

Quoted 15 lines · Yann E. MORIN

Quoted 14 lines
Yes, it *is* functionally equivalent. It just looks weird that you have to define the kernel version after (as 'as a conseuence of) the headers version, since logically, it is the opposite that one would want.
However, as you said, it would not be very practical to implement that in a user-friendly way:
- on one hand, it seems totally more logical to define the toolchain options before enblign a kernel,
- on the other hand, the kernel headers version is very dependent on the running kernel version.
Chicken'n'egg problem... :-(

Quoted 8 lines

Quoted 1 line
So, do we agree that we should drop this patch?
I also don't like the way the patch is implemented, but I think the problem raised by this patch is real. Sometimes people have kernel sources that contain some custom kernel headers needed for their userspace libraries/applications, and we have no mechanism to allow them to use their custom kernel source for the linux-headers package, which is a bit annoying.

Ah... I just looked, and indeed all we have is an option to manually specify the version, nad there is no way to use any of the other sources that we have for the kernel (tarball, git tree...)

Indeed, we do not have the same functionality.

So, what should we do:

- "duplicate" for the headers the many ways we have to retrieve a kernel's source tree?

- find a better way to implement Karoly's needs?

IIRC, I think I already suggested that we set the version string from Kconfig, a bit like:

choice
bool "headers version"

[...]

config BR2_PKG_HEADERS_AS_KERNEL
bool "like kernel"
depends on BR2_LINUX_KERNEL

comment "blabla needs a kernel to be built"
depends on !BR2_LINUX_KERNEL

[...]

endchoice

config BR2_DEFAULT_KERNEL_HEADERS
string
default BR2_LINUX_KERNEL_VERSION if BR2_PKG_HEADERS_AS_KERNEL

Which will avoid having to deal with tricky Makefile code like this patch does.

(Yes, it is possible to use another Kconfig variable as a default value.)

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

Thomas Petazzoni

2016-01-18 22:21 UTC #9 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Yann,

Quoted 15 lines · Yann E. MORIN

IIRC, I think I already suggested that we set the version string from Kconfig, a bit like:
choice
bool "headers version"
[...]
config BR2_PKG_HEADERS_AS_KERNEL
bool "like kernel"
depends on BR2_LINUX_KERNEL
comment "blabla needs a kernel to be built"
depends on !BR2_LINUX_KERNEL

Quoted 7 lines

[...]
endchoice
config BR2_DEFAULT_KERNEL_HEADERS
string
default BR2_LINUX_KERNEL_VERSION if BR2_PKG_HEADERS_AS_KERNEL

This is not sufficient. If you select "custom tarball", or "local", then BR2_LINUX_KERNEL_VERSION just contains "custom". Or it will contain just the Git tag/commit id, or just the Mercurial version. You still lack the repo/tarball URL/local directory.

But if you have a proposal based on that, that takes into account those issues, don't hesitate to submit a patch.

Alternatively, what we could do is simply duplicate some code from linux.mk into linux-headers.mk and therefore have linux-header.mk directly poke at the linux/Config.in variables. Not nice, but it solves a long-standing request, and we don't change that often the Linux download/patch logic.

I was trying to think of getting rid of the linux-headers package and have the linux package provide the headers for the toolchain, but I don't see a really feasible way of doing this.

Best regards,

Thomas

Signature · 3 lines

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

Peter Korsgaard

2016-01-18 22:21 UTC #10 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

In reply to Thomas Petazzoni

Quoted 10 lines

Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
So, do we agree that we should drop this patch?
I also don't like the way the patch is implemented, but I think the problem raised by this patch is real. Sometimes people have kernel sources that contain some custom kernel headers needed for their userspace libraries/applications, and we have no mechanism to allow them to use their custom kernel source for the linux-headers package, which is a bit annoying.

Yeah, true. It does require that these custom header files are really exported (so they get installed by headers_install) which in my experience is not always the case.

What I have told people to do in the past instead is to either copy the needed definitions into their user space code or add -I$(LINUX_DIR)/include (if they build their kernel in Buildroot) like E.G. xdriver_xf86-video-imx does it.

Signature · 2 lines

Venlig hilsen,
Peter Korsgaard

Thomas Petazzoni

2016-01-18 22:24 UTC #11 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Peter,

Quoted 7 lines · Peter Korsgaard

Quoted 6 lines
I also don't like the way the patch is implemented, but I think the problem raised by this patch is real. Sometimes people have kernel sources that contain some custom kernel headers needed for their userspace libraries/applications, and we have no mechanism to allow them to use their custom kernel source for the linux-headers package, which is a bit annoying.

Quoted 8 lines

Yeah, true. It does require that these custom header files are really exported (so they get installed by headers_install) which in my experience is not always the case.
What I have told people to do in the past instead is to either copy the needed definitions into their user space code or add -I$(LINUX_DIR)/include (if they build their kernel in Buildroot) like E.G. xdriver_xf86-video-imx does it.

Yes, I know there are ways around it.

But it does seem weird to many users that the "linux" package provides some many possibilities for fetching/patching the kernel, and still the linux-headers package downloads a completely different kernel version, with less possibilities of using a custom version.

Thomas

Signature · 3 lines

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

Peter Korsgaard

2016-01-19 08:21 UTC #12 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Quoted 16 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Peter,
Quoted 11 lines · Peter Korsgaard
Quoted 6 lines
I also don't like the way the patch is implemented, but I think the problem raised by this patch is real. Sometimes people have kernel sources that contain some custom kernel headers needed for their userspace libraries/applications, and we have no mechanism to allow them to use their custom kernel source for the linux-headers package, which is a bit annoying.
Yeah, true. It does require that these custom header files are really exported (so they get installed by headers_install) which in my experience is not always the case.

Quoted 6 lines

Quoted 4 lines
What I have told people to do in the past instead is to either copy the needed definitions into their user space code or add -I$(LINUX_DIR)/include (if they build their kernel in Buildroot) like E.G. xdriver_xf86-video-imx does it.
Yes, I know there are ways around it.

But these "workarounds" are the only real solutions if you want to be able to use existing binary toolchains.

Quoted 4 lines

But it does seem weird to many users that the "linux" package provides some many possibilities for fetching/patching the kernel, and still the linux-headers package downloads a completely different kernel version, with less possibilities of using a custom version.

So perhaps we need an option to use the linux source for our kernel headers? It does mean that people need to jump back and forth between the toolchain and linux menus.

Signature · 2 lines

Venlig hilsen,
Peter Korsgaard

Thomas Petazzoni

2016-01-19 10:18 UTC #13 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Peter,

Quoted 8 lines · Peter Korsgaard

Quoted 4 lines
But it does seem weird to many users that the "linux" package provides some many possibilities for fetching/patching the kernel, and still the linux-headers package downloads a completely different kernel version, with less possibilities of using a custom version.
So perhaps we need an option to use the linux source for our kernel headers? It does mean that people need to jump back and forth between the toolchain and linux menus.

Adding the option is not the problem. The problem is that from package/linux-headers/linux-headers.mk, you can't use variables defined from linux/linux.mk. So all you can do in package/linux-headers/linux-headers.mk is duplicate the logic from linux/linux.mk that will calculate LINUX_HEADERS_{VERSION,SITE,SOURCE} and apply the custom patches from the BR2_LINUX_KERNEL_* Config.in values.

Thomas

Signature · 3 lines

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

Peter Korsgaard

2016-01-19 10:29 UTC #14 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Quoted 1 line

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

Hi,

Quoted 11 lines

Quoted 3 lines
So perhaps we need an option to use the linux source for our kernel headers? It does mean that people need to jump back and forth between the toolchain and linux menus.
Adding the option is not the problem. The problem is that from package/linux-headers/linux-headers.mk, you can't use variables defined from linux/linux.mk. So all you can do in package/linux-headers/linux-headers.mk is duplicate the logic from linux/linux.mk that will calculate LINUX_HEADERS_{VERSION,SITE,SOURCE} and apply the custom patches from the BR2_LINUX_KERNEL_* Config.in values.

Well, linux-headers doesn't need to do much - So with a bit of care I think you can.

E.G. something like (completely untested):

ifeq ($(LINUX_HEADERS_FROM_KERNEL),y)

# no source
LINUX_HEADERS_SOURCE =
LINUX_HEADERS_DEPENDENCIES += linux-configure
LINUX_HEADERS_BUILD_DIR = $(LINUX_DIR)
else
..
LINUX_HEADERS_BUILD_DIR = $(@D)
endif

..
define LINUX_HEADERS_INSTALL_STAGING_CMDS

	(cd $(LINUX_HEADERS_BUILD_DIR); \
		$(TARGET_MAKE_ENV) $(MAKE) \

But it isn't very pretty / robust.

Signature · 2 lines

Venlig hilsen,
Peter Korsgaard

Thomas Petazzoni

2016-01-19 10:31 UTC #15 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Dear Peter Korsgaard,

Quoted 9 lines · Peter Korsgaard

Well, linux-headers doesn't need to do much - So with a bit of care I think you can.
E.G. something like (completely untested):
ifeq ($(LINUX_HEADERS_FROM_KERNEL),y)
# no source
LINUX_HEADERS_SOURCE =
LINUX_HEADERS_DEPENDENCIES += linux-configure

The configure step of a package depends on the dependencies of that package. So linux-configure depends on toolchain. And toolchain depends on linux-headers -> recursive dependency.

Another try ? :-)

Thomas

Signature · 3 lines

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

Peter Korsgaard

2016-01-19 10:37 UTC #16 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Quoted 1 line

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

Hi,

Quoted 13 lines

Dear Peter Korsgaard,
Quoted 9 lines · Peter Korsgaard
Well, linux-headers doesn't need to do much - So with a bit of care I think you can.
E.G. something like (completely untested):
ifeq ($(LINUX_HEADERS_FROM_KERNEL),y)
# no source
LINUX_HEADERS_SOURCE =
LINUX_HEADERS_DEPENDENCIES += linux-configure

Quoted 5 lines

The configure step of a package depends on the dependencies of that package. So linux-configure depends on toolchain. And toolchain depends on linux-headers -> recursive dependency.
Another try ? :-)

Then linux-patch, we afaik don't need a configured linux kernel to make headers_install

Signature · 2 lines

Venlig hilsen,
Peter Korsgaard

Yann E. MORIN

2016-01-19 17:22 UTC #17 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Peter, Thomas, All,

On 2016-01-19 11:37 +0100, Peter Korsgaard spake thusly:

Quoted 14 lines

Quoted 13 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Dear Peter Korsgaard,
Quoted 9 lines · Peter Korsgaard
Well, linux-headers doesn't need to do much - So with a bit of care I think you can.
E.G. something like (completely untested):
ifeq ($(LINUX_HEADERS_FROM_KERNEL),y)
# no source
LINUX_HEADERS_SOURCE =
LINUX_HEADERS_DEPENDENCIES += linux-configure

Quoted 7 lines

Quoted 5 lines
The configure step of a package depends on the dependencies of that package. So linux-configure depends on toolchain. And toolchain depends on linux-headers -> recursive dependency.
Another try ? :-)
Then linux-patch, we afaik don't need a configured linux kernel to make headers_install

Indeed, that's a good idea. We propbably could use set:

LINUX_HEADERS_PATCH_DEPENDENCIES = linux

which will guarantee that linux is patched before linux-headers is configured (in the Buildroot sense).

Then, we basically could do:

    define LINUX_HEADERS_INSTALL_STAGING_CMDS
        $(MAKE) -C $(LINUX_DIR) INSTALL_HDR_PATH=$(STAGING_DIR)/usr
    endef

(with extra variables as done today, of course...)

There, we can use $(LINUX_DIR) because the macro is only expanded in a make rule, so we should be fine. Hopefully...

I can have a look at this.

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

Arnout Vandecappelle

2016-01-18 17:42 UTC #18 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

In reply to Yann E. MORIN

Quoted 14 lines · Yann E. MORIN

Karoly, All,
Reviving this old one that is still pending in Patchwork...
On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
Quoted 6 lines
This change makes it possible to use exactly the same sources for both headers during toolchain building and for kernel building itself, even if custom kernel is selected.
That way users can be sure that ABI mismatch won't happen between toolchain and kernel.
So, I'll try to summarise what we have for now:

Quoted 7 lines

- select kernel headers version and select kernel version (separately)
- select kernel headers version, also used as kernel version.
What you want to add with this patch is:
- select kernel version, also used as kernel headers version.

Actually, I think the main purpose of this patch is to take the same source for
kernel-headers as you use when building the kernel. This is particularly important if your kernel is some wild branch that adds extra userspace stuff (typically, ioctl definitions, but it could also be struct definitions). Failing this, you have to pass a reference to LINUX_DIR to the build of the package that uses these symbols.

That said, it's been years since I ran into such a braindead package that
required specific custom kernel headers. Except for some wicked Broadcom stuff, of course, but that probably doesn't even build with our linux.mk rules.

Regards,
Arnout

Signature · 6 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Алексей Бродкин

2016-01-19 07:25 UTC #19 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

Hi Arnout, all

2016-01-18 20:42 GMT+03:00 Arnout Vandecappelle <[email protected]>:

Quoted 30 lines · Yann E. MORIN

Quoted 14 lines
Karoly, All,
Reviving this old one that is still pending in Patchwork...
On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
Quoted 6 lines
This change makes it possible to use exactly the same sources for both headers during toolchain building and for kernel building itself, even if custom kernel is selected.
That way users can be sure that ABI mismatch won't happen between toolchain and kernel.
So, I'll try to summarise what we have for now:
Quoted 7 lines
- select kernel headers version and select kernel version (separately)
- select kernel headers version, also used as kernel version.
What you want to add with this patch is:
- select kernel version, also used as kernel headers version.
Actually, I think the main purpose of this patch is to take the same source for
kernel-headers as you use when building the kernel. This is particularly important if your kernel is some wild branch that adds extra userspace stuff (typically, ioctl definitions, but it could also be struct definitions). Failing this, you have to pass a reference to LINUX_DIR to the build of the package that uses these symbols.

Quoted 3 lines

That said, it's been years since I ran into such a braindead package that
required specific custom kernel headers. Except for some wicked Broadcom stuff, of course, but that probably doesn't even build with our linux.mk rules.

From my experience discussed functionality is very convenient in case kernel ABI gets changed. Indeed and fortunately that happens quite seldom but nevertheless it happens sometimes. And I may easily foresee such situation in the future - just imagine
another architecture becomes 64-bit (like ARC, Microblaze, xtensa you name it).

So IMHO it's good to be prepared.

-Alexey

Yann E. MORIN

2016-01-19 20:10 UTC #20 lore raw

PATCH v4 1/1 linux-headers: allow use of headers from kernel "package" selected

In reply to Karoly Kasza

Karoly, All,

On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:

Quoted 8 lines

This change makes it possible to use exactly the same sources for both headers during toolchain building and for kernel building itself, even if custom kernel is selected.
That way users can be sure that ABI mismatch won't happen between toolchain and kernel.
Signed-off-by Karoly Kasza <[email protected]>

We've discussed this at length, both on this threads and on IRC, and we've come to the conclusion that the implementation you proposed is not acceptable.

However, Peter suggested an alternate path, and I've implemented a proof of concept that seems to be working quite OK. I'll refine it and post it on the list soonish.

In the meantime, we've marked your patch as "changes requested" on Patchwork.

Thanks for spawning the discussion! :-)

Regards,
Yann E. MORIN.

Quoted 123 lines

---

Changes v3 -> v4:
- Rebased to cleanly apply again

 linux/Config.in                        |    1 +
 linux/linux.mk                         |    7 +++++++
 package/linux-headers/Config.in.host   |   14 ++++++++++++--
 package/linux-headers/linux-headers.mk |    9 +++++++++
 4 files changed, 29 insertions(+), 2 deletions(-)

linux/Config.in +1 -0

index c981493..30faaaf 100644
@@ -26,6 +26,7 @@ config BR2_LINUX_KERNEL_LATEST_VERSION
 config BR2_LINUX_KERNEL_SAME_AS_HEADERS
 	bool "Same as toolchain kernel headers"
 	depends on BR2_TOOLCHAIN_BUILDROOT
+	depends on !BR2_KERNEL_HEADERS_SAME_AS_KERNEL
 	help
 	  This option will re-use the same kernel sources as the one
 	  that have been used for the kernel headers of the

linux/linux.mk +7 -0

index 0b8c912..29d93db 100644
@@ -8,6 +8,9 @@ LINUX_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
 LINUX_LICENSE = GPLv2
 LINUX_LICENSE_FILES = COPYING
 
+# Compute variables as a function, so linux-headers can call it when needed
+define BR2_LINUX_COMPUTE_VARS
+
 # Compute LINUX_SOURCE and LINUX_SITE from the configuration
 ifeq ($(BR2_LINUX_KERNEL_CUSTOM_TARBALL),y)
 LINUX_TARBALL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION))

@@ -40,6 +43,10 @@ LINUX_SITE := $(LINUX_SITE)/testing/
 endif # -rc
 endif
 
+endef
+
+$(eval $(BR2_LINUX_COMPUTE_VARS))
+
 LINUX_PATCHES = $(call qstrip,$(BR2_LINUX_KERNEL_PATCH))
 
 LINUX_INSTALL_IMAGES = YES

package/linux-headers/Config.in.host +12 -2

index 2755f2f..7a06224 100644
@@ -5,6 +5,7 @@ comment "Kernel Header Options"
 
 choice
 	prompt "Kernel Headers"
+	default BR2_KERNEL_HEADERS_SAME_AS_KERNEL if BR2_LINUX_KERNEL
 	default BR2_KERNEL_HEADERS_3_18
 	help
 	  Select the version of kernel header files you wish to use.

@@ -69,6 +70,13 @@ choice
 
 	config BR2_KERNEL_HEADERS_VERSION
 		bool "Manually specified Linux version"
+
+	config BR2_KERNEL_HEADERS_SAME_AS_KERNEL
+		bool "Use Linux kernel specified for target"
+		depends on BR2_LINUX_KERNEL
+		help
+		  Use the Linux kernel specified for the target in
+		  the Kernel menu.
 endchoice
 
 config BR2_DEFAULT_KERNEL_VERSION

@@ -80,10 +88,12 @@ 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_SAME_AS_KERNEL
 	default BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD
 	help
-	  Set to the kernel headers series you manually set above.
+	  Set to the kernel headers series you manually entered in
+	  "linux version" field or matching version of specific kernel selected
+	  for building in "kernel" section.
 
 	  This is used to hide/show some packages that have strict
 	  requirements on the version of kernel headers.

package/linux-headers/linux-headers.mk +9 -0

index d770927..b4a1c8d 100644
@@ -7,6 +7,14 @@
 # This package is used to provide Linux kernel headers for the
 # internal toolchain backend.
 
+ifeq ($(BR2_KERNEL_HEADERS_SAME_AS_KERNEL),y)
+# Force computing the variables from the Kernel package
+$(eval $(BR2_LINUX_COMPUTE_VARS))
+LINUX_HEADERS_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION))
+LINUX_HEADERS_SOURCE = $(LINUX_SOURCE)
+LINUX_HEADERS_SITE = $(LINUX_SITE)
+LINUX_HEADERS_SITE_METHOD = $(LINUX_SITE_METHOD)
+else
 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

@@ -14,6 +22,7 @@ else
 LINUX_HEADERS_SITE = $(BR2_KERNEL_MIRROR)/linux/kernel/v3.x
 endif
 LINUX_HEADERS_SOURCE = linux-$(LINUX_HEADERS_VERSION).tar.xz
+endif
 
 LINUX_HEADERS_INSTALL_STAGING = YES

Signature · 6 lines

1.7.10.4

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

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