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

[Yann E. MORIN <yann.morin.1998@free.fr>]

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