Re: Staging machine specific kernel headers in sysroot

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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