Staging machine specific kernel headers in sysroot

Staging machine specific kernel headers in sysroot

[Andre McCurdy]

Say I have a kernel driver with a user space API (simple struct and
ioctl definitions) defined in a header file which is part of my
machine specific kernel. The header file is not found in the upstream
kernel, so doesn't clash with anything in linux-libc-headers.

Is it OK to use something like the following in my kernel recipe?

  sysroot_stage_all_append () {
    install -d ${SYSROOT_DESTDIR}/${includedir}/linux
    install -m644 ${S}/include/linux/foo.h
${SYSROOT_DESTDIR}/${includedir}/linux/
  }

I've tested it and everything seems to work fine, but I'm wondering if
bypassing do_install like that is going to cause problems somehow?

Re: Staging machine specific kernel headers in sysroot

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

You should write a bbappend for linux libc headers recipe and apply the
patch to kernel and expose is that way. But before doing that I would
suggest that you work with driver owner to submit their header to kernel.
Since you can get into conflicts in future.
On Apr 1, 2016 8:38 PM, "Andre McCurdy" <armccurdy@gmail.com> wrote:

> Say I have a kernel driver with a user space API (simple struct and
> ioctl definitions) defined in a header file which is part of my
> machine specific kernel. The header file is not found in the upstream
> kernel, so doesn't clash with anything in linux-libc-headers.
>
> Is it OK to use something like the following in my kernel recipe?
>
>   sysroot_stage_all_append () {
>     install -d ${SYSROOT_DESTDIR}/${includedir}/linux
>     install -m644 ${S}/include/linux/foo.h
> ${SYSROOT_DESTDIR}/${includedir}/linux/
>   }
>
> I've tested it and everything seems to work fine, but I'm wondering if
> bypassing do_install like that is going to cause problems somehow?
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 1698 bytes --]

Re: Staging machine specific kernel headers in sysroot

[Richard Purdie]

On Fri, 2016-04-01 at 20:38 -0700, Andre McCurdy wrote:
> Say I have a kernel driver with a user space API (simple struct and
> ioctl definitions) defined in a header file which is part of my
> machine specific kernel. The header file is not found in the upstream
> kernel, so doesn't clash with anything in linux-libc-headers.
> 
> Is it OK to use something like the following in my kernel recipe?
> 
>   sysroot_stage_all_append () {
>     install -d ${SYSROOT_DESTDIR}/${includedir}/linux
>     install -m644 ${S}/include/linux/foo.h
> ${SYSROOT_DESTDIR}/${includedir}/linux/
>   }
> 
> I've tested it and everything seems to work fine, but I'm wondering
> if
> bypassing do_install like that is going to cause problems somehow?

You can probably just do it in do_install to be honest, then on target
development would also work.

The trouble we usually have is that people expect more and more kernel
headers to be installed/usable (e.g. to build complete modules against)
until we have a complete build of the kernel there, at which point you
really want to use the kernel shared work directory instead. We did
pretty much the full circle on that.

Or people go the other route and hack linux-libc-headers to install
their header as well, and then the whole system including the compiler
becomes machine specific. I appreciate you're not doing that, I just
want this answer to mention it as that is a much worse idea and the
comments in that recipe reflect some bad experiences for good reason.

So in summary, you can probably do that reasonably safely, on the
understanding that any user of that header will also become machine
specific with a kernel build dependency. There is risk of overlap if
upstream do create such a header or API but its probably not a huge
deal.

Cheers,

Richard

Re: Staging machine specific kernel headers in sysroot

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]


> On Apr 2, 2016, at 1:48 AM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> On Fri, 2016-04-01 at 20:38 -0700, Andre McCurdy wrote:
>> Say I have a kernel driver with a user space API (simple struct and
>> ioctl definitions) defined in a header file which is part of my
>> machine specific kernel. The header file is not found in the upstream
>> kernel, so doesn't clash with anything in linux-libc-headers.
>> 
>> Is it OK to use something like the following in my kernel recipe?
>> 
>>  sysroot_stage_all_append () {
>>    install -d ${SYSROOT_DESTDIR}/${includedir}/linux
>>    install -m644 ${S}/include/linux/foo.h
>> ${SYSROOT_DESTDIR}/${includedir}/linux/
>>  }
>> 
>> I've tested it and everything seems to work fine, but I'm wondering
>> if
>> bypassing do_install like that is going to cause problems somehow?
> 
> You can probably just do it in do_install to be honest, then on target
> development would also work.
> 
> The trouble we usually have is that people expect more and more kernel
> headers to be installed/usable (e.g. to build complete modules against)
> until we have a complete build of the kernel there, at which point you
> really want to use the kernel shared work directory instead. We did
> pretty much the full circle on that.
> 
> Or people go the other route and hack linux-libc-headers to install
> their header as well, and then the whole system including the compiler
> becomes machine specific. I appreciate you're not doing that, I just
> want this answer to mention it as that is a much worse idea and the
> comments in that recipe reflect some bad experiences for good reason.
> 
> So in summary, you can probably do that reasonably safely, on the
> understanding that any user of that header will also become machine
> specific with a kernel build dependency. There is risk of overlap if
> upstream do create such a header or API but its probably not a huge
> deal.

if its really not to be treated as global kernel UAPI then wouldn’t it be
better to inherit kernelsrc and access it relative to STAGING_KERNEL_DIR ?
if you put it in UAPI namespace doesn't matter which recipe brings it in
the SDKs will get those APIs regardless who puts it there so you still have
the global UAPI namespace contamination that you are trying to avoid in
first place.



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: Staging machine specific kernel headers in sysroot

[Mike Looijmans]

On 02-04-16 10:48, Richard Purdie wrote:
> On Fri, 2016-04-01 at 20:38 -0700, Andre McCurdy wrote:
>> Say I have a kernel driver with a user space API (simple struct and
>> ioctl definitions) defined in a header file which is part of my
>> machine specific kernel. The header file is not found in the upstream
>> kernel, so doesn't clash with anything in linux-libc-headers.
>>
>> Is it OK to use something like the following in my kernel recipe?
>>
>>    sysroot_stage_all_append () {
>>      install -d ${SYSROOT_DESTDIR}/${includedir}/linux
>>      install -m644 ${S}/include/linux/foo.h
>> ${SYSROOT_DESTDIR}/${includedir}/linux/
>>    }
>>
>> I've tested it and everything seems to work fine, but I'm wondering
>> if
>> bypassing do_install like that is going to cause problems somehow?
>
> You can probably just do it in do_install to be honest, then on target
> development would also work.

A simple method to get around the header being "kernel" related is to create a 
second recipe referring the same repository as the module, but that just 
installs the header. That turns it into a simple "library" dependency instead 
of making things machine-specific.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail