Patchwork [RFC] don't run make clean on kernel_do_install

login
register
mail settings
Submitter Koen Kooi
Date April 23, 2011, 2:47 p.m.
Message ID <73DFD7AC-9837-4C27-BB34-2B2AC7D1DD8B@dominion.thruhere.net>
Download mbox | patch
Permalink /patch/2787/
State New, archived
Headers show

Comments

Koen Kooi - April 23, 2011, 2:47 p.m.
Hi,

Over the holidays I was trying to build some externel kernel modules and they failed to build because linux/bounds.h wasn't in sysroots.

I did this quick hack to work around it:


I'm not convinced that the above is the right way to solve it, but I lack the required kbuild knowledge to come up with a better one. Does anyone have a hint on how to approach this problem in a better way?

regards,

Koen
Darren Hart - April 25, 2011, 5:10 p.m.
Hi Koen,

On 04/23/2011 07:47 AM, Koen Kooi wrote:
> Hi,
> 
> Over the holidays I was trying to build some externel kernel modules
> and they failed to build because linux/bounds.h wasn't in sysroots.
> 


According the the linux Makefile:

###
# Cleaning is done on three levels.
# make clean     Delete most generated files
#                Leave enough to build external modules

The kernel Makefile should not be deleting it.

And indeed:
https://bugzilla.kernel.org/show_bug.cgi?id=11475

This was addressed by the following in 2.6.27:
7d3cc8b6d899e53222c22a78d98bb53a695f7962
Don't clean bounds.h and asm-offsets.h

Later, bounds.h moved as well in 2.6.33:
01fc0ac198eabcbf460e1ed058860a935b6c2c9a
kbuild: move bounds.h to include/generated


Which kernel version are you attempting to build?

We shouldn't add code to address a bug in a specific kernel version in a
kernel base class. That belongs in the specific recipe. I suggest trying
to add the 7d3cc8b6d899e53222c22a78d98bb53a695f7962 patch to your kernel
recipe and see if that resolves the issue for you without resorting to
recreating the clean process in the base class.

--
Darren

> I did this quick hack to work around it:
>
> --- a/meta-oe/classes/kernel.bbclass
> +++ b/meta-oe/classes/kernel.bbclass
> @@ -159,7 +159,8 @@ kernel_do_install() {
>         # we clean the scripts dir while leaving the generated config
>         # and include files.
>         #
> -       oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
> +       find $kerneldir -name "*.o" -delete
> +       #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/Documentation -name "*.txt" -exec rm '{}' \;
> 
> I'm not convinced that the above is the right way to solve it, but I
> lack the required kbuild knowledge to come up with a better one. Does
> anyone have a hint on how to approach this problem in a better way?
> 
> regards,
> 
> Koen
Koen Kooi - April 25, 2011, 6:28 p.m.
Op 25 apr 2011, om 19:10 heeft Darren Hart het volgende geschreven:

> Hi Koen,
> 
> On 04/23/2011 07:47 AM, Koen Kooi wrote:
>> Hi,
>> 
>> Over the holidays I was trying to build some externel kernel modules
>> and they failed to build because linux/bounds.h wasn't in sysroots.
>> 
> 
> 
> According the the linux Makefile:
> 
> ###
> # Cleaning is done on three levels.
> # make clean     Delete most generated files
> #                Leave enough to build external modules
> 
> The kernel Makefile should not be deleting it.
> 
> And indeed:
> https://bugzilla.kernel.org/show_bug.cgi?id=11475
> 
> This was addressed by the following in 2.6.27:
> 7d3cc8b6d899e53222c22a78d98bb53a695f7962
> Don't clean bounds.h and asm-offsets.h
> 
> Later, bounds.h moved as well in 2.6.33:
> 01fc0ac198eabcbf460e1ed058860a935b6c2c9a
> kbuild: move bounds.h to include/generated
> 
> 
> Which kernel version are you attempting to build?

The 2.6.32 kernel from TI

> 
> We shouldn't add code to address a bug in a specific kernel version in a
> kernel base class. That belongs in the specific recipe. I suggest trying
> to add the 7d3cc8b6d899e53222c22a78d98bb53a695f7962 patch to your kernel
> recipe and see if that resolves the issue for you without resorting to
> recreating the clean process in the base class.

That's already in :(

koen@dominion:/OE/tentacle/build/tmp-angstrom_2010_x/work/beagleboard-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r99a+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/git$ grep bound Kbuild 
# 1) Generate bounds.h
# 2) Generate asm-offsets.h (may need bounds.h)
# 1) Generate bounds.h
bounds-file := include/linux/bounds.h
always  := $(bounds-file)
targets := $(bounds-file) kernel/bounds.s
quiet_cmd_bounds = GEN     $@
define cmd_bounds
kernel/bounds.s: kernel/bounds.c FORCE
$(obj)/$(bounds-file): kernel/bounds.s Kbuild
	$(call cmd,bounds)
                                      $(obj)/$(bounds-file) FORCE
clean-files := $(addprefix $(objtree)/,$(filter-out $(bounds-file) $(offsets-file),$(targets)))

I'll dig a bit deeper to see why bounds.h is getting cleaned.

regards,

Koen


> 
> --
> Darren
> 
>> I did this quick hack to work around it:
>> 
>> --- a/meta-oe/classes/kernel.bbclass
>> +++ b/meta-oe/classes/kernel.bbclass
>> @@ -159,7 +159,8 @@ kernel_do_install() {
>>        # we clean the scripts dir while leaving the generated config
>>        # and include files.
>>        #
>> -       oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>> +       find $kerneldir -name "*.o" -delete
>> +       #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/Documentation -name "*.txt" -exec rm '{}' \;
>> 
>> I'm not convinced that the above is the right way to solve it, but I
>> lack the required kbuild knowledge to come up with a better one. Does
>> anyone have a hint on how to approach this problem in a better way?
>> 
>> regards,
>> 
>> Koen
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
Koen Kooi - April 28, 2011, 8:30 a.m.
Op 25 apr 2011, om 19:10 heeft Darren Hart het volgende geschreven:

> Hi Koen,
> 
> On 04/23/2011 07:47 AM, Koen Kooi wrote:
>> Hi,
>> 
>> Over the holidays I was trying to build some externel kernel modules
>> and they failed to build because linux/bounds.h wasn't in sysroots.
>> 
> 
> 
> According the the linux Makefile:
> 
> ###
> # Cleaning is done on three levels.
> # make clean     Delete most generated files
> #                Leave enough to build external modules
> 
> The kernel Makefile should not be deleting it.
> 
> And indeed:
> https://bugzilla.kernel.org/show_bug.cgi?id=11475
> 
> This was addressed by the following in 2.6.27:
> 7d3cc8b6d899e53222c22a78d98bb53a695f7962
> Don't clean bounds.h and asm-offsets.h
> 
> Later, bounds.h moved as well in 2.6.33:
> 01fc0ac198eabcbf460e1ed058860a935b6c2c9a
> kbuild: move bounds.h to include/generated
> 
> 
> Which kernel version are you attempting to build?
> 
> We shouldn't add code to address a bug in a specific kernel version in a
> kernel base class. That belongs in the specific recipe. I suggest trying
> to add the 7d3cc8b6d899e53222c22a78d98bb53a695f7962 patch to your kernel
> recipe and see if that resolves the issue for you without resorting to
> recreating the clean process in the base class.

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

regards,

Koen
Darren Hart - April 28, 2011, 3:26 p.m.
On 04/28/2011 01:30 AM, Koen Kooi wrote:
> 
> Op 25 apr 2011, om 19:10 heeft Darren Hart het volgende geschreven:
> 
>> Hi Koen,
>>
>> On 04/23/2011 07:47 AM, Koen Kooi wrote:
>>> Hi,
>>>
>>> Over the holidays I was trying to build some externel kernel modules
>>> and they failed to build because linux/bounds.h wasn't in sysroots.
>>>
>>
>>
>> According the the linux Makefile:
>>
>> ###
>> # Cleaning is done on three levels.
>> # make clean     Delete most generated files
>> #                Leave enough to build external modules
>>
>> The kernel Makefile should not be deleting it.
>>
>> And indeed:
>> https://bugzilla.kernel.org/show_bug.cgi?id=11475
>>
>> This was addressed by the following in 2.6.27:
>> 7d3cc8b6d899e53222c22a78d98bb53a695f7962
>> Don't clean bounds.h and asm-offsets.h
>>
>> Later, bounds.h moved as well in 2.6.33:
>> 01fc0ac198eabcbf460e1ed058860a935b6c2c9a
>> kbuild: move bounds.h to include/generated
>>
>>
>> Which kernel version are you attempting to build?
>>
>> We shouldn't add code to address a bug in a specific kernel version in a
>> kernel base class. That belongs in the specific recipe. I suggest trying
>> to add the 7d3cc8b6d899e53222c22a78d98bb53a695f7962 patch to your kernel
>> recipe and see if that resolves the issue for you without resorting to
>> recreating the clean process in the base class.
> 
> I went with this option: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/commit/?id=7bcba149f05cc9c5d8ce956ee40e2c6849601470
> 

Works around the problem, but does so in the appropriate place. I would
like to understand if this is something that is likely to bite others,
or if there is something peculiar about this particular kernel. If it
crops up again, we'll need to dig in further.

--
Darren

> regards,
> 
> Koen

Patch

--- a/meta-oe/classes/kernel.bbclass
+++ b/meta-oe/classes/kernel.bbclass
@@ -159,7 +159,8 @@  kernel_do_install() {
        # we clean the scripts dir while leaving the generated config
        # and include files.
        #
-       oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
+       find $kerneldir -name "*.o" -delete
+       #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/Documentation -name "*.txt" -exec rm '{}' \;