[OE-core] Patch for fixing build issues with external kernel modules.

[Darren Hart]

On 05/09/2011 06:56 PM, Franz Leitl wrote:
> Hi,
> 
> Am Dienstag 10 Mai 2011, 03:40:04 schrieb Franz Leitl:
>> Am Montag 09 Mai 2011, 22:53:19 schrieben Sie:
>>> The kernel should not remove bounds.h, that is documented in the
>>> Makefile. If it does, it's a bug.
>>
>> After executing "bitbake -f -c compile virtual/kernel"  I get bounds.h in
>> "${S}/includes/generated/".
>> Seems as if both
>>     oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>> and
>>     make -C $kerneldir _mrproper_scripts
>> in kernel.bbclass are to blame for removing bounds.h from
>> "$kerneldir/includes/generated/".
>> I tested it twice. Only in case both lines are commented out bounds.h stays
>> in "$kerneldir/includes/generated/"
> I still would like to know, what to do next.
> 
>> What to do with module.bbclass not setting KERNEL_PATH in
>> module_do_install? My Makefile relies on it, if KERNEL_PATH is not set it
>> will use
>> "/lib/modules/$(shell uname -r)/build" instead. But uname returns the
>> host's kernel version.
>> Is there any reason why oe_runmake in module_do_compile sets
>> "KERNEL_PATH=${STAGING_KERNEL_DIR}" while in module_do_install it doesn't?
>> Should I overwrite the do_install in my recipe or should module.bbclass be
>> fixed?
> Ok, I just remembered the hint to recipes-kernel/hello-mod/files/Makefile. Works 
> as KERNEL_SRC is also set to ${STAGING_KERNEL_DIR}. But it does not explain what 
> the real difference between KERNEL_SRC and KERNEL_PATH is, as both are set to 
> the same value and why does module_do_install not set KERNEL_PATH but 
> module_do_compile does?

I took a look at the poky.git meta classes (oe-core) and the history of
the oe.git version of module.bbclass from which this was derived several
years back. The current OE version sets both KERNEL_SRC and KERNEL_PATH.
I don't know of any need for KERNEL_PATH - or more specifically, I don't
see a need for both. In my experience KERNEL_SRC is more commonly used.
It is a more explicit name than the _PATH variation as it is clear it
points to the sources.

I'll have a look at how OE and oe-core have diverged, but unless I find
something unexpected, I would like to remove KERNEL_PATH from the
compile step as well.

--
Darren

> 
> 
> Regards,
> Franz
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel