Created attachment 1542 [details] bbclass to make sanitized kernel headers available for a recipe In a recent commit (http://cgit.openembedded.org/openembedded-core/commit/?id=c27ac156bcaf3193d52f456480947b0cfaef3c72), Richard added a big warning about not forking the linux-libc-headers recipe to get at specific kernel headers for user space. As a consequence I thought I should remove our fork of linux-libc-headers and instead use the suggested method of including the needed files from ${STAGING_KERNEL_DIR} in the recipes that need them. However, I soon realized that what I need are the sanitized headers that are generated by running "make headers_install" in the kernel sources. So what I then did was to create a simple bbclass that generates them for me and makes them available for my recipe (see attachment). After that I could simply do 'inherit kernel-headers' and 'CFLAGS += "-I${KINCLUDES}/includes"' in my recipe to get at the sanitized kernel headers. But, it seems somewhat wasteful for each recipe that need those headers to do that. It would be better if the sanitized headers were provided once for all to use (similar to ${STAGING_KERNEL_DIR} for the kernel sources). When I asked about this on the OE mailing list, Bruce Ashfield replied: I've proposed similar solutions in the past, including installing the headers into the sysroot along side of the libc-headers in "usr-alt/", or "kernel-headers/", rather than within the kernel staging dir, since the staging dir is often tar'd up and added to things like the kernel-dev package or SDKs .. and if not properly installed, you can clash with the libc usr/include/linux headers. But yes, either way, I'm all for doing this once, making them available in a oe-core "standard" location, as long as it isn't picked up by default include paths. If you want to open up something in the bugzilla, we can take care of this early in the yocto 1.6 cycle, since at this point in 1.5, we don't want to jiggle much of anything :)
I'll grab this one. Thanks for the report.
Moving this to 1.7, since it better matches the developer experience theme. In flight patches will be rebased and submitted then.
*** Bug 4119 has been marked as a duplicate of this bug. ***
*** Bug 7866 has been marked as a duplicate of this bug. ***
working on cleaning this up, to have two modes .. one that does something like the attached bbclass, and another that packages the alternate headers (so it can be reused).
Created attachment 4647 [details] dual mode headers patch
(In reply to comment #6) > Created attachment 4647 [details] > dual mode headers patch Two comments about the patch: * You should use "${KERNEL_PACKAGE_NAME}-headers-alt" instead of "kernel-headers-alt" as package name. * Some lines in the shell functions use a mix of spaces and tabs for indentation rather than all tabs.
(In reply to comment #7) > (In reply to comment #6) > > Created attachment 4647 [details] > > dual mode headers patch > > Two comments about the patch: > > * You should use "${KERNEL_PACKAGE_NAME}-headers-alt" instead of > "kernel-headers-alt" as package name. Actually, I named it this way on purpose. It isn't actually supposed to be used, it is a placeholder against QA errors. But yes, there's no harm in following whatever naming is in a given kernel recipe. > * Some lines in the shell functions use a mix of spaces and tabs for > indentation rather than all tabs. Noted. This isn't the final version, just a placeholder. This isn't being sent out until post release and will have more revision before then. People were asking about this, so I wanted to put the WIP someplace they could find.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Created attachment 4647 [details] > > > dual mode headers patch > > > > Two comments about the patch: > > > > * You should use "${KERNEL_PACKAGE_NAME}-headers-alt" instead of > > "kernel-headers-alt" as package name. > > Actually, I named it this way on purpose. It isn't actually supposed to be > used, it is a placeholder against QA errors. But yes, there's no harm in > following whatever naming is in a given kernel recipe. > > > * Some lines in the shell functions use a mix of spaces and tabs for > > indentation rather than all tabs. > > Noted. This isn't the final version, just a placeholder. > > This isn't being sent out until post release and will have more revision > before then. People were asking about this, so I wanted to put the WIP > someplace they could find. I've run tabify on the functions, they are all consistent now!
I tried the mode 1 approach with the patch (0001-kernel-provide-alternate-headers-for-package-specifi.patch) applied to my bsp layer (I am using yocto version 3.1 and yoe distro). The target application was able to find the exported kernel headers. However I see one side effect that kernel menuconfig command can't run anymore. bitbake virtual/kernel -c menuconfig *** *** The source tree is not clean, please run 'make mrproper' *** in /home/workspace/yoe-dmabuf/build/tmp/work-shared/qemuarm64/kernel-source *** make[1]: *** [outputmakefile] Error 1 make: *** [sub-make] Error 2 Command failed. Press any key to continue... Is this because make headers_install was run from KERNEL_STAGING_DIRECTORY ? It works after doing a cleanall on virtual/kernel first.
A small change to the patch helps mitigate the side effect. do_compile_prepend() { if [ "${KERNEL_SOURCE_IS_LOCAL}" = "False" ]; then # install from the staging kernel directory oe_runmake -C ${STAGING_KERNEL_DIR} headers_install INSTALL_HDR_PATH=${WORKDIR}/${KERNEL_ALT_HEADER_DIR} oe_runmake -C ${STAGING_KERNEL_DIR} mrproper fi }
mode 2 worked fine.
Created attachment 4825 [details] updated bbclass for new overrides this is the same bbclass that I've attached before, with the last comment change integrated and update to the new override syntax.
Bulk move of medium importance bugs from 5.1 to 5.2 on behalf of Bruce.