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

Алексей Бродкин alexey.brodkin at gmail.com
Tue Jan 19 07:25:58 UTC 2016


Hi Arnout, all

2016-01-18 20:42 GMT+03:00 Arnout Vandecappelle <arnout at 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


More information about the buildroot mailing list