Patch for fixing build issues with external kernel modules.

Patch for fixing build issues with external kernel modules.

[Franz Leitl]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

Hi,

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 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. I also added KERNELDIR as compcache's Makefile is using it and the 
classes from classic OE had it also set.

Can someone please review the attached patch?


Regards,
Franz

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

[Franz Leitl]

[-- Attachment #1: Type: Text/Plain, Size: 2332 bytes --]

Hi,

Hopefully this time the patch is "attached".

Regards
Franz

---
 meta/classes/kernel.bbclass |    2 +-
 meta/classes/module.bbclass |    9 ++++++++-
 2 files changed, 9 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..e5b705a 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -11,13 +11,18 @@ 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() {
+
+
        do_make_scripts
        unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
        oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
+                   KERNELDIR=${STAGING_KERNEL_DIR}  \
                   KERNEL_SRC=${STAGING_KERNEL_DIR}    \
                   KERNEL_VERSION=${KERNEL_VERSION}    \
                   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
@@ -28,6 +33,8 @@ module_do_compile() {
 module_do_install() {
        unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
        oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
+                   KERNEL_PATH=${STAGING_KERNEL_DIR}   \
+                   KERNELDIR=${STAGING_KERNEL_DIR}  \
                   KERNEL_SRC=${STAGING_KERNEL_DIR} \
                   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
                   modules_install
-- 
1.7.1

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

[Darren Hart]

On Mon, 2011-05-09 at 00:16 +0200, Franz Leitl wrote:
> Hi,
> 
> 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.

> 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

So I'm curious about your workflow and why you are hitting these two
issues. Can you share your recipes?

>  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.

> 
> Can someone please review the attached patch?
> 
> 
> 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

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

[Franz Leitl]

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(-)

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
-- 
1.7.1

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

[Koen Kooi]

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

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

[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-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

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

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

[Franz Leitl]

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

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

[Darren Hart]

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,

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

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

[Franz Leitl]

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

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

[Franz Leitl]

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

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

[Darren Hart]

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

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

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

[Franz Leitl]

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

Re: 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

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

[Darren Hart]

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

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

[Darren Hart]

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
Intel Open Source Technology Center
Yocto Project - Linux Kernel