[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Karoly Kasza]

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 <kaszak@gmail.com>
---

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

diff --git a/linux/Config.in b/linux/Config.in
index c981493..30faaaf 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -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
diff --git a/linux/linux.mk b/linux/linux.mk
index 0b8c912..29d93db 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -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
diff --git a/package/linux-headers/Config.in.host b/package/linux-headers/Config.in.host
index 2755f2f..7a06224 100644
--- a/package/linux-headers/Config.in.host
+++ b/package/linux-headers/Config.in.host
@@ -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.
diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk
index d770927..b4a1c8d 100644
--- a/package/linux-headers/linux-headers.mk
+++ b/package/linux-headers/linux-headers.mk
@@ -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
 
-- 
1.7.10.4

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Thomas Petazzoni]

Dear Karoly Kasza,

On Sun,  1 Mar 2015 18:17:55 +0100, Karoly Kasza wrote:
> diff --git a/linux/linux.mk b/linux/linux.mk
> index 0b8c912..29d93db 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -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))

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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

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

Hi Thomas,

2015-03-05 1:37 GMT+03:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Dear Karoly Kasza,
>
> On Sun,  1 Mar 2015 18:17:55 +0100, Karoly Kasza wrote:
>> diff --git a/linux/linux.mk b/linux/linux.mk
>> index 0b8c912..29d93db 100644
>> --- a/linux/linux.mk
>> +++ b/linux/linux.mk
>> @@ -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))
>
> 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.

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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

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

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 v4] linux-headers: allow use of headers from kernel "package" selected

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Karoly, All,
 > Reviving this old one that is still pending in Patchwork...

 > On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
 >> 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.

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.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Arnout Vandecappelle]

On 09-01-16 18:29, Yann E. MORIN wrote:
> Karoly, All,
> 
> Reviving this old one that is still pending in Patchwork...
> 
> On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
>> 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.

 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


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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Yann E. MORIN]

Peter, Karoly, All,

On 2016-01-18 10:21 +0100, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> 
>  > Karoly, All,
>  > Reviving this old one that is still pending in Patchwork...
> 
>  > On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
>  >> 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.
> 
> I think part of the reason we have it this way is purely historical

Yes, it 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.

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

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

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 v4] linux-headers: allow use of headers from kernel "package" selected

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

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

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

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

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Thomas Petazzoni]

Yann,

On Mon, 18 Jan 2016 22:47:04 +0100, Yann E. MORIN wrote:

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

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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Yann E. MORIN]

Thomas, All,

On 2016-01-18 23:03 +0100, Thomas Petazzoni spake thusly:
> On Mon, 18 Jan 2016 22:47:04 +0100, Yann E. MORIN wrote:
> 
> > 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?
> 
> 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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 v4] linux-headers: allow use of headers from kernel "package" selected

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 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.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Thomas Petazzoni]

Yann,

On Mon, 18 Jan 2016 23:13:43 +0100, Yann E. MORIN wrote:

> 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

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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Thomas Petazzoni]

Peter,

On Mon, 18 Jan 2016 23:21:08 +0100, Peter Korsgaard wrote:

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

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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

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

Hi Arnout, all

2016-01-18 20:42 GMT+03:00 Arnout Vandecappelle <arnout@mind.be>:
> On 09-01-16 18:29, Yann E. MORIN wrote:
>> Karoly, All,
>>
>> Reviving this old one that is still pending in Patchwork...
>>
>> On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
>>> 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.
>
>  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.

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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Peter Korsgaard]

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

 > Peter,
 > On Mon, 18 Jan 2016 23:21:08 +0100, Peter Korsgaard wrote:

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

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


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

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Thomas Petazzoni]

Peter,

On Tue, 19 Jan 2016 09:21:49 +0100, Peter Korsgaard wrote:

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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Peter Korsgaard]

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

Hi,

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

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Tue, 19 Jan 2016 11:29:08 +0100, Peter Korsgaard wrote:

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

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Peter Korsgaard]

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

Hi,

 > Dear Peter Korsgaard,
 > On Tue, 19 Jan 2016 11:29:08 +0100, Peter Korsgaard wrote:

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

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

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH v4] linux-headers: allow use of headers from kernel "package" selected

[Yann E. MORIN]

Peter, Thomas, All,

On 2016-01-19 11:37 +0100, Peter Korsgaard spake thusly:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>  > Dear Peter Korsgaard,
>  > On Tue, 19 Jan 2016 11:29:08 +0100, Peter Korsgaard wrote:
> 
>  >> 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 ? :-)
> 
> 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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 v4] linux-headers: allow use of headers from kernel "package" selected

[Yann E. MORIN]

Karoly, All,

On 2015-03-01 18:17 +0100, Karoly Kasza spake thusly:
> 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 <kaszak@gmail.com>

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.

> ---
> 
> 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(-)
> 
> diff --git a/linux/Config.in b/linux/Config.in
> index c981493..30faaaf 100644
> --- a/linux/Config.in
> +++ b/linux/Config.in
> @@ -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
> diff --git a/linux/linux.mk b/linux/linux.mk
> index 0b8c912..29d93db 100644
> --- a/linux/linux.mk
> +++ b/linux/linux.mk
> @@ -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
> diff --git a/package/linux-headers/Config.in.host b/package/linux-headers/Config.in.host
> index 2755f2f..7a06224 100644
> --- a/package/linux-headers/Config.in.host
> +++ b/package/linux-headers/Config.in.host
> @@ -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.
> diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk
> index d770927..b4a1c8d 100644
> --- a/package/linux-headers/linux-headers.mk
> +++ b/package/linux-headers/linux-headers.mk
> @@ -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
>  
> -- 
> 1.7.10.4
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

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