On 07/11/2012 07:48 AM, Richard Purdie wrote: > On Wed, 2012-07-11 at 07:25 -0700, Khem Raj wrote: >> On Wed, Jul 11, 2012 at 3:30 AM, Richard Purdie >> <richard.pur...@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.
Khem, I take it we still have something left to do here in addition to the bounds.h patch you sent a short while ago? If so, this sounds like a big enough effort that a bug is warranted. Would you consider writing up exactly what you're trying to accomplish and opening a bug? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
