Patchwork Patch for fixing build issues with external kernel modules.

login
register
mail settings
Submitter Franz Leitl
Date May 9, 2011, 5:32 p.m.
Message ID <201105091932.06238.leitl@fim.uni-passau.de>
Download mbox | patch
Permalink /patch/3483/
State New, archived
Headers show

Comments

Franz Leitl - May 9, 2011, 5:32 p.m.
Hi,

Am Montag 09 Mai 2011, 18:28:06 schrieben Sie:
> > I've tried to get compcache kernel module building against 2.6.34 from
> > shr- core but found some issues with kernel.bbclass and module.bbclass.
> > 
> > The kernel.bbclass deletes the .c files from scripts directory which are
> > later needed by make prepare to recreate bound.h and other files.
> > Compcache kernel module, for example, depends on bounds.h.
> 
> The bounds.h should not need to be recreated. It is created during the
> build of the kernel, and since 2.6.26, the makefile knows not to remove
> it.
Compache does not build without bounds.h and this file is missing in the staging directory for what ever reason.

> > The module.bbclass finally needs to call "make prepare" and also set
> > KERNEL_PATH in do_install when calling oe_runmake to get everything
> > installed correctly.
> 
> Since we copy over the source tree after a simple clean, make prepare
> should also not be necessary:
> 
>   clean		  - Remove most generated files but keep the config and
>                     enough build support to build external modules
I could not find bounds.h in the staging directory, thus i tried to recreate it with "make prepare" which failed as "make prepare" complains about missing bounds.c which was note deleted by "make clean" but the kernel.bbclass' extra cleaning of the script directory.
Even if "make prepare" may not be necessary in most cases shouldn't it be fixed so that it would work properly in case someone really needs it?

> So I'm curious about your workflow and why you are hitting these two
> issues. Can you share your recipes?
Workflow? I've just tried to build the compache recipe from classic OE which I have modified to use the latest source from compcache mercurial repository and added some stuff so it works with oe-core.
Why I'm hitting those problems is explained above.
I can send the recipe, but I have to prepare a patch first, as compcache needs some additional patches to build with OE/bitbake.

> >  I also added KERNELDIR as compcache's Makefile is using it and the
> > classes from classic OE had it also set.
> 
> I'm not familiar with compcache, but generally speaking we can't get in
> the habit of modifying the recipe classes to support whatever variables
> random external module Makefile expect. See recipes-kernel/hello-mod for
> an example Makefile that builds an external module using the existing
> infrastructure. You may just need a patch to the compcache Makefile for
> it to work within the existing infrastructure.
I already have to patch the Makefile, so changing the Makefile's KERNELDIR to OE's KERNEL_PATH would be no problem.

I removed the KERNELDIR as suggested, hope the patch is included and a bit more acceptable this time.


Regards,
Franz


---
 meta/classes/kernel.bbclass |    2 +-
 meta/classes/module.bbclass |    5 ++++-
 2 files changed, 5 insertions(+), 2 deletions(-)
Koen Kooi - May 9, 2011, 5:53 p.m.
Op 9 mei 2011, om 19:32 heeft Franz Leitl het volgende geschreven:

> Hi,
> 
> Am Montag 09 Mai 2011, 18:28:06 schrieben Sie:
>>> I've tried to get compcache kernel module building against 2.6.34 from
>>> shr- core but found some issues with kernel.bbclass and module.bbclass.
>>> 
>>> The kernel.bbclass deletes the .c files from scripts directory which are
>>> later needed by make prepare to recreate bound.h and other files.
>>> Compcache kernel module, for example, depends on bounds.h.
>> 
>> The bounds.h should not need to be recreated. It is created during the
>> build of the kernel, and since 2.6.26, the makefile knows not to remove
>> it.
> Compache does not build without bounds.h and this file is missing in the staging directory for what ever reason.

I ran into the same and I did the following:

http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/commit/?id=7bcba149f05cc9c5d8ce956ee40e2c6849601470

regards,

Koen
Darren Hart - May 9, 2011, 6:20 p.m.
On 05/09/2011 10:32 AM, Franz Leitl wrote:
> Hi,
> 
> Am Montag 09 Mai 2011, 18:28:06 schrieben Sie:
>>> I've tried to get compcache kernel module building against 2.6.34 from
>>> shr- core but found some issues with kernel.bbclass and module.bbclass.
>>>
>>> The kernel.bbclass deletes the .c files from scripts directory which are
>>> later needed by make prepare to recreate bound.h and other files.
>>> Compcache kernel module, for example, depends on bounds.h.
>>
>> The bounds.h should not need to be recreated. It is created during the
>> build of the kernel, and since 2.6.26, the makefile knows not to remove
>> it.
> Compache does not build without bounds.h and this file is missing in the staging directory for what ever reason.


Which version of oe-core are you using?


> 
>>> The module.bbclass finally needs to call "make prepare" and also set
>>> KERNEL_PATH in do_install when calling oe_runmake to get everything
>>> installed correctly.
>>
>> Since we copy over the source tree after a simple clean, make prepare
>> should also not be necessary:
>>
>>   clean		  - Remove most generated files but keep the config and
>>                     enough build support to build external modules
> I could not find bounds.h in the staging directory, thus i tried to recreate it with "make prepare" which failed as "make prepare" complains about missing bounds.c which was note deleted by "make clean" but the kernel.bbclass' extra cleaning of the script directory.
> Even if "make prepare" may not be necessary in most cases shouldn't it be fixed so that it would work properly in case someone really needs it?


It should be fixed, yes, but not here. If bounds.h is being removed, the
fix is to prevent that from happening, not regenerate later.

--
Darren


> 
>> So I'm curious about your workflow and why you are hitting these two
>> issues. Can you share your recipes?
> Workflow? I've just tried to build the compache recipe from classic OE which I have modified to use the latest source from compcache mercurial repository and added some stuff so it works with oe-core.
> Why I'm hitting those problems is explained above.
> I can send the recipe, but I have to prepare a patch first, as compcache needs some additional patches to build with OE/bitbake.
> 
>>>  I also added KERNELDIR as compcache's Makefile is using it and the
>>> classes from classic OE had it also set.
>>
>> I'm not familiar with compcache, but generally speaking we can't get in
>> the habit of modifying the recipe classes to support whatever variables
>> random external module Makefile expect. See recipes-kernel/hello-mod for
>> an example Makefile that builds an external module using the existing
>> infrastructure. You may just need a patch to the compcache Makefile for
>> it to work within the existing infrastructure.
> I already have to patch the Makefile, so changing the Makefile's KERNELDIR to OE's KERNEL_PATH would be no problem.
> 
> I removed the KERNELDIR as suggested, hope the patch is included and a bit more acceptable this time.
> 
> 
> Regards,
> Franz
> 
> 
> ---
>  meta/classes/kernel.bbclass |    2 +-
>  meta/classes/module.bbclass |    5 ++++-
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 70a782f..9835130 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -149,7 +149,7 @@ kernel_do_install() {
>  	#
>  	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>  	make -C $kerneldir _mrproper_scripts
> -	find $kerneldir -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
> +	find $kerneldir -path $kerneldir/scripts -prune -o -name "*.[sS]" -exec rm '{}' \;
>  	find $kerneldir/Documentation -name "*.txt" -exec rm '{}' \;
>  
>  	# Remove the following binaries which cause strip errors
> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
> index 572df0d..eeb7772 100644
> --- a/meta/classes/module.bbclass
> +++ b/meta/classes/module.bbclass
> @@ -11,7 +11,9 @@ inherit module-base
>  do_make_scripts() {
>  	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
>  	oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> -	           -C ${STAGING_KERNEL_DIR} scripts
> +		-C ${STAGING_KERNEL_DIR} scripts
> +	oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> +		-C ${STAGING_KERNEL_DIR} prepare
>  }
>  
>  module_do_compile() {
> @@ -28,6 +30,7 @@ module_do_compile() {
>  module_do_install() {
>  	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>  	oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
> +		KERNEL_PATH=${STAGING_KERNEL_DIR}   \
>  	           KERNEL_SRC=${STAGING_KERNEL_DIR} \
>  	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>  	           modules_install
Darren Hart - May 9, 2011, 6:23 p.m.
On 05/09/2011 10:53 AM, Koen Kooi wrote:
> 
> Op 9 mei 2011, om 19:32 heeft Franz Leitl het volgende geschreven:
> 
>> Hi,
>>
>> Am Montag 09 Mai 2011, 18:28:06 schrieben Sie:
>>>> I've tried to get compcache kernel module building against 2.6.34 from
>>>> shr- core but found some issues with kernel.bbclass and module.bbclass.
>>>>
>>>> The kernel.bbclass deletes the .c files from scripts directory which are
>>>> later needed by make prepare to recreate bound.h and other files.
>>>> Compcache kernel module, for example, depends on bounds.h.
>>>
>>> The bounds.h should not need to be recreated. It is created during the
>>> build of the kernel, and since 2.6.26, the makefile knows not to remove
>>> it.
>> Compache does not build without bounds.h and this file is missing in the staging directory for what ever reason.
> 
> I ran into the same and I did the following:
> 
> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/commit/?id=7bcba149f05cc9c5d8ce956ee40e2c6849601470

Thanks Koen, I knew we had discussed this once before. In your case,
IIRC, you found that the "make clean" deleted bounds.h, even with the
fix from 2.6.26 applied.

At the time we agreed that patching the kernel bbclasses for a bug in a
particular kernel version wasn't a good plan. I'm concerned that Franz
is hitting this with 2.6.34.

Franz, can you confirm that bounds.h exists before the clean and does
not exist after the clean? Some simple instrumentation to kernel.bbclass
should be able to do this.

If so, we need to look into why that is happening. Simply not deleting
the C files from the source isn't an acceptable fix to save 1 file.

--
Darren

> 
> regards,
> 
> Koen
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Franz Leitl - May 9, 2011, 6:38 p.m.
Am Montag 09 Mai 2011, 20:23:19 schrieb Darren Hart:
> On 05/09/2011 10:53 AM, Koen Kooi wrote:
> > Op 9 mei 2011, om 19:32 heeft Franz Leitl het volgende geschreven:
> >> Hi,
> >> 
> >> Am Montag 09 Mai 2011, 18:28:06 schrieben Sie:
> >>>> I've tried to get compcache kernel module building against 2.6.34 from
> >>>> shr- core but found some issues with kernel.bbclass and
> >>>> module.bbclass.
> >>>> 
> >>>> The kernel.bbclass deletes the .c files from scripts directory which
> >>>> are later needed by make prepare to recreate bound.h and other files.
> >>>> Compcache kernel module, for example, depends on bounds.h.
> >>> 
> >>> The bounds.h should not need to be recreated. It is created during the
> >>> build of the kernel, and since 2.6.26, the makefile knows not to remove
> >>> it.
> >> 
> >> Compache does not build without bounds.h and this file is missing in the
> >> staging directory for what ever reason.
> > 
> > I ran into the same and I did the following:
> > 
> > http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstrumen
> > ts/commit/?id=7bcba149f05cc9c5d8ce956ee40e2c6849601470
> 
> Thanks Koen, I knew we had discussed this once before. In your case,
> IIRC, you found that the "make clean" deleted bounds.h, even with the
> fix from 2.6.26 applied.
> 
> At the time we agreed that patching the kernel bbclasses for a bug in a
> particular kernel version wasn't a good plan. I'm concerned that Franz
> is hitting this with 2.6.34.
> 
> Franz, can you confirm that bounds.h exists before the clean and does
> not exist after the clean? Some simple instrumentation to kernel.bbclass
> should be able to do this.
I'll try to find out.

> If so, we need to look into why that is happening. Simply not deleting
> the C files from the source isn't an acceptable fix to save 1 file.
The c files are deleted by the kernel.bbclass not by "make clean" while make 
clean deletes the bounds.h... Who is doing the wrong thing now? kernel.bbclass 
removing the bounds.c, kernel's make clean removing the bounds.h or the module 
author relying on modules.h?

I don't know if/what the problem is with regenerating some things in 
module.bbclass. It is already done with "make scripts". Cleaning up 
things to save diskspace and recreating if needed does not seem to 
bad to me. Am I missing something?


Regards,
Franz
Darren Hart - May 9, 2011, 8:53 p.m.
On 05/09/2011 11:38 AM, Franz Leitl wrote:
> Am Montag 09 Mai 2011, 20:23:19 schrieb Darren Hart:
>> On 05/09/2011 10:53 AM, Koen Kooi wrote:
>>> Op 9 mei 2011, om 19:32 heeft Franz Leitl het volgende geschreven:
>>>> Hi,
>>>>
>>>> Am Montag 09 Mai 2011, 18:28:06 schrieben Sie:
>>>>>> I've tried to get compcache kernel module building against 2.6.34 from
>>>>>> shr- core but found some issues with kernel.bbclass and
>>>>>> module.bbclass.
>>>>>>
>>>>>> The kernel.bbclass deletes the .c files from scripts directory which
>>>>>> are later needed by make prepare to recreate bound.h and other files.
>>>>>> Compcache kernel module, for example, depends on bounds.h.
>>>>>
>>>>> The bounds.h should not need to be recreated. It is created during the
>>>>> build of the kernel, and since 2.6.26, the makefile knows not to remove
>>>>> it.
>>>>
>>>> Compache does not build without bounds.h and this file is missing in the
>>>> staging directory for what ever reason.
>>>
>>> I ran into the same and I did the following:
>>>
>>> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstrumen
>>> ts/commit/?id=7bcba149f05cc9c5d8ce956ee40e2c6849601470
>>
>> Thanks Koen, I knew we had discussed this once before. In your case,
>> IIRC, you found that the "make clean" deleted bounds.h, even with the
>> fix from 2.6.26 applied.
>>
>> At the time we agreed that patching the kernel bbclasses for a bug in a
>> particular kernel version wasn't a good plan. I'm concerned that Franz
>> is hitting this with 2.6.34.
>>
>> Franz, can you confirm that bounds.h exists before the clean and does
>> not exist after the clean? Some simple instrumentation to kernel.bbclass
>> should be able to do this.
> I'll try to find out.
> 
>> If so, we need to look into why that is happening. Simply not deleting
>> the C files from the source isn't an acceptable fix to save 1 file.
> The c files are deleted by the kernel.bbclass not by "make clean" while make 
> clean deletes the bounds.h... Who is doing the wrong thing now? kernel.bbclass 
> removing the bounds.c, kernel's make clean removing the bounds.h or the module 
> author relying on modules.h?

The kernel should not remove bounds.h, that is documented in the
Makefile. If it does, it's a bug.

> 
> I don't know if/what the problem is with regenerating some things in 
> module.bbclass. It is already done with "make scripts". Cleaning up 
> things to save diskspace and recreating if needed does not seem to 
> bad to me. Am I missing something?

The scripts are regenerated as they are host specific. If you were to
use an sstate package, you don't want host-specific binaries in it. (We
aren't there yet, but we want to keep that in mind).

It's just about fixing it properly instead of applying a band-aid.
Regenerating something that shouldn't have been deleted in the first
place is a band-aid, and you can go that route in your own recipe if you
like (per Koen's patch), but that doesn't belong in the core kernel classes.

Thanks,
Franz Leitl - May 10, 2011, 1:40 a.m.
Hi,

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/".
What to do next?

> It's just about fixing it properly instead of applying a band-aid.
> Regenerating something that shouldn't have been deleted in the first
> place is a band-aid, and you can go that route in your own recipe if you
> like (per Koen's patch), but that doesn't belong in the core kernel
> classes.
I prefer a proper fix, whatever it might look like.


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?


Regards,
Franz
Franz Leitl - May 10, 2011, 1:56 a.m.
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?


Regards,
Franz
Darren Hart - May 10, 2011, 8:23 p.m.
Hi Franz, I'm not ignoring you, I'm laid up in bed with a nasty stomach
flu and not thinking very clearly right now. I'll try and responds as
soon as I can...

--
Darren

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?
> 
> 
> Regards,
> Franz
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Franz Leitl - May 10, 2011, 10:50 p.m.
Hi Darren,

Am Dienstag 10 Mai 2011, 22:23:13 schrieben Sie:
> Hi Franz, I'm not ignoring you, I'm laid up in bed with a nasty stomach
> flu and not thinking very clearly right now. I'll try and responds as
> soon as I can...
No need to rush. I can wait. I used the workaround from Koen Kooi for getting 
the bounds.h in the meantime and changed the Makefile to use KERNEL_SRC. Just 
cannot test anything as I pulled the latest stuff from openembedded-core and 
something is broken now. I'm also busy with other things, so it's not too 
important to me.


Regards,
Franz
Darren Hart - May 23, 2011, 11:37 p.m.
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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Darren Hart - May 24, 2011, 12:19 a.m.
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
>

Patch

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 70a782f..9835130 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -149,7 +149,7 @@  kernel_do_install() {
 	#
 	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
 	make -C $kerneldir _mrproper_scripts
-	find $kerneldir -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
+	find $kerneldir -path $kerneldir/scripts -prune -o -name "*.[sS]" -exec rm '{}' \;
 	find $kerneldir/Documentation -name "*.txt" -exec rm '{}' \;
 
 	# Remove the following binaries which cause strip errors
diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index 572df0d..eeb7772 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -11,7 +11,9 @@  inherit module-base
 do_make_scripts() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
 	oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
-	           -C ${STAGING_KERNEL_DIR} scripts
+		-C ${STAGING_KERNEL_DIR} scripts
+	oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
+		-C ${STAGING_KERNEL_DIR} prepare
 }
 
 module_do_compile() {
@@ -28,6 +30,7 @@  module_do_compile() {
 module_do_install() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
 	oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
+		KERNEL_PATH=${STAGING_KERNEL_DIR}   \
 	           KERNEL_SRC=${STAGING_KERNEL_DIR} \
 	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
 	           modules_install