Re: [PATCH 2/2] kernel.bbclass: Make tree available for cross building external modules

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2012-07-11 at 07:25 -0700, Khem Raj wrote:
> On Wed, Jul 11, 2012 at 3:30 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Tue, 2012-07-10 at 10:07 -0700, Khem Raj wrote:
> >> We shave too much from kernel sources for making it work
> >> for on device external kernel module development that cross
> >> development of external modules wont work from same tree
> >> anymore. This patch makes a copy of tree which will eventually
> >> be staged for building external modules
> >
> > It sounds from the further discussion that there is more to the patch
> > than just this. Firstly, a change like this needs a more precise
> > description.
> >
> > Secondly, we're copying around *way* to much data in this approach. I'd
> > like to suggest an improvement but can't since the description above is
> > lacking, I can't even understand what the problem is you're trying to
> > fix.
> 
> alright. There are tools (especially in scripts/) which are made for
> buildhost when compiling the kernel irrespective of cross
> or native. The tools like fixdep, recordmcount etc. which are needed
> to run when you build kernel itself as well as external
> modules. Now we do 'make _mproper_scripts' which cleans all those
> binaries. We do this because we want to ship kernel-dev
> and packaging binaries for different host wont be allowed in a target
> package. So we chose to delete them and then on device
> regenerate them ( ideally I would have preferred to generate them
> cross candian when making for target)
> 
> Deleting these tools also renders the cross building of modules
> useless. Since I want to ship the sources as reference only
> meaning people may not have write access to the kernel sources they
> can not run make inside the kernel sources to regenerate
> those binaries before they start building their external modules.
> 
> >
> > So more discussion is needed.
> >
> > I have a suspicion that this fix only "happens" to work when SDKMACHINE
> > == NATIVEMACHINE.
> >
> 
> yes, for a full solution we have to generate two versions of
> kernel-tools 1 for target and 1 for SDKMACHINE
> however this at least brings back what we had.

s/full/non-broken/

This patch adds something that is broken in several different cases and
kills off performance as an added bonus. I'd like to get this fixed
properly please rather than perpetuate the problem. We need to either do
something well and correctly, or not do it at all. We could document
"make _mproper_scripts" as a requirement for installing the kernel SDK
in the meantime.

I think we do need to make a kernel-tools package which correctly
generates the tools for a given target, be it nativesdk, or the target
device.

Cheers,

Richard