Patchwork kernel.bbclass: Don't include source files for "other" architectures in the sysroot

login
register
mail settings
Submitter Phil Blundell
Date April 29, 2013, 2:02 p.m.
Message ID <1367244122.14512.124.camel@phil-desktop.brightsign>
Download mbox | patch
Permalink /patch/49061/
State New
Headers show

Comments

Phil Blundell - April 29, 2013, 2:02 p.m.
Since the sysroot is per-machine, we can be fairly confident that any
out-of-tree modules which look at our sources will be building for the
same architecture that we are.  This being the case there's no need to
ship the sources for any other architectures, which saves disk space and
time (about 30 seconds in do_package, in a somewhat unscientific test
with ARCH=mips).

Of course, an even better fix would be to not install these files in the
first place, but deleting them is easier.

Signed-off-by: Phil Blundell <philb@gnu.org>
---
 meta/classes/kernel.bbclass |    1 +
 1 file changed, 1 insertion(+)
Darren Hart - May 1, 2013, 7:08 p.m.
On 04/29/2013 07:02 AM, Phil Blundell wrote:
> Since the sysroot is per-machine, we can be fairly confident that any
> out-of-tree modules which look at our sources will be building for the
> same architecture that we are.  This being the case there's no need to
> ship the sources for any other architectures, which saves disk space and
> time (about 30 seconds in do_package, in a somewhat unscientific test
> with ARCH=mips).
> 
> Of course, an even better fix would be to not install these files in the
> first place, but deleting them is easier.

No objection, and reducing kernel related build/package time is a good
thing.

You've stated that this successfully removes code on mips, have you also
tested that basic module building still works? For example, does
hello-mod still build?

Have you confirmed this on any other architectures? I'd like to see a
test at least on the core emulated BSPs (or maybe at least 2 of them)
before we pull this in as we have spent quite a bit of effort getting
modules building to date, I'd hate to break that due to a lack of testing.

> 
> Signed-off-by: Phil Blundell <philb@gnu.org>
> ---
>  meta/classes/kernel.bbclass |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 00e27ef..ffb0b11 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -167,6 +167,7 @@ kernel_do_install() {
>  	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>  	make -C $kerneldir _mrproper_scripts
>  	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
> +	rm -rf $(find $kerneldir/arch -maxdepth 1 -not -path $kerneldir/arch/$ARCH -not -path $kerneldir/arch/Kconfig -not -path $kerneldir/arch/. -not -path $kerneldir/arch)

Any particular reason for not using "-exec rm" like the other code
removal commands here?

>  	find $kerneldir/Documentation -name "*.txt" -exec rm '{}' \;
>  
>  	# As of Linux kernel version 3.0.1, the clean target removes
> 

Thanks,
Phil Blundell - May 1, 2013, 9:05 p.m.
On Wed, 2013-05-01 at 12:08 -0700, Darren Hart wrote:
> You've stated that this successfully removes code on mips, have you also
> tested that basic module building still works? For example, does
> hello-mod still build?

I didn't try hello-mod, but the two (proprietary) out-of-tree modules
that we routinely build into our own images do still compile and work.

> Have you confirmed this on any other architectures? I'd like to see a
> test at least on the core emulated BSPs (or maybe at least 2 of them)
> before we pull this in as we have spent quite a bit of effort getting
> modules building to date, I'd hate to break that due to a lack of testing.

I've tested on arm and mips.  I guess I can set up a build tree for a
qemu target on some other architecture if you like.

> >  	make -C $kerneldir _mrproper_scripts
> >  	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
> > +	rm -rf $(find $kerneldir/arch -maxdepth 1 -not -path $kerneldir/arch/$ARCH -not -path $kerneldir/arch/Kconfig -not -path $kerneldir/arch/. -not -path $kerneldir/arch)
> 
> Any particular reason for not using "-exec rm" like the other code
> removal commands here?

No, just force of habit.  Using xargs is more performant in general, but
"find -exec ..." is safer and I guess that's probably what we should do
here too.

p.
Darren Hart - May 1, 2013, 9:10 p.m.
On 05/01/2013 02:05 PM, Phil Blundell wrote:
> On Wed, 2013-05-01 at 12:08 -0700, Darren Hart wrote:
>> You've stated that this successfully removes code on mips, have you also
>> tested that basic module building still works? For example, does
>> hello-mod still build?
> 
> I didn't try hello-mod, but the two (proprietary) out-of-tree modules
> that we routinely build into our own images do still compile and work.
> 
>> Have you confirmed this on any other architectures? I'd like to see a
>> test at least on the core emulated BSPs (or maybe at least 2 of them)
>> before we pull this in as we have spent quite a bit of effort getting
>> modules building to date, I'd hate to break that due to a lack of testing.
> 
> I've tested on arm and mips.  I guess I can set up a build tree for a
> qemu target on some other architecture if you like.


I'd feel more comfortable with a bit more testing as this impacts all
architecture and that sometimes has subtle effects.


>>>  	make -C $kerneldir _mrproper_scripts
>>>  	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
>>> +	rm -rf $(find $kerneldir/arch -maxdepth 1 -not -path $kerneldir/arch/$ARCH -not -path $kerneldir/arch/Kconfig -not -path $kerneldir/arch/. -not -path $kerneldir/arch)
>>
>> Any particular reason for not using "-exec rm" like the other code
>> removal commands here?
> 
> No, just force of habit.  Using xargs is more performant in general, but
> "find -exec ..." is safer and I guess that's probably what we should do
> here too.

OK, I'll wait for the next version.

Patch

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 00e27ef..ffb0b11 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -167,6 +167,7 @@  kernel_do_install() {
 	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
 	make -C $kerneldir _mrproper_scripts
 	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
+	rm -rf $(find $kerneldir/arch -maxdepth 1 -not -path $kerneldir/arch/$ARCH -not -path $kerneldir/arch/Kconfig -not -path $kerneldir/arch/. -not -path $kerneldir/arch)
 	find $kerneldir/Documentation -name "*.txt" -exec rm '{}' \;
 
 	# As of Linux kernel version 3.0.1, the clean target removes