Bug 5305

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.