[OE-core] Staging machine specific kernel headers in sysroot

[Khem Raj]

> On Apr 2, 2016, at 1:48 AM, Richard Purdie <richard.purdie at 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160402/cba1314e/attachment-0002.sig>