Re: Patch for fixing build issues with external kernel modules.

[Darren Hart <dvhart@linux.intel.com>]

On 05/23/2011 04:37 PM, Darren Hart wrote:
> 
> 
> 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.
> 


After reviewing the changes that have gone in to oe since the version I
see in oe-core, I think I need to change my thinking on this. There is
precedent for adding commonly used KERNEL_SRC variants to the
module.bbclass. It appears that a refresh of the module infrastructure
is required. Adding to my todo list:

http://bugzilla.yoctoproject.org/show_bug.cgi?id=1094


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

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