[OE-core] [PATCH V2] [RFC] kernel: rework kernel and module classes to allow for building out-of-tree modules
Koen Kooi
koen at beagleboard.org
Wed Mar 16 17:54:05 UTC 2011
Op 16 mrt 2011, om 18:04 heeft Darren Hart het volgende geschreven:
> NOT FOR INCLUSION
>
> Before we include something like this, it needs review from folks like Koen and
> Gary to confirm it works in their environment as well.
>
> The existing infrastructure uses an external build tree which references the
> kernel source in the work dir. If run with rm work, building external modules
> will fail.
>
> This patch places a configured source tree in sysroots. Striking a balance
> between minimal size and minimal maintenance is difficult. A fully configured
> tree is about 500MB after a clean. This version leans on the side of caution and
> removes only the obviously unecessary parts of the source tree to conserve
> space, resulting in about 170MB. The arch directories would be some additional
> pruning we could do. Given examples from the devel package from distributions, I
> suspect this size could be reduced to 75MB or so, but at the cost of a much more
> complex recipe which is likely to require a great deal more maintenance to keep
> current with kernel releases.
>
> Care is also taken to clean the hostprogs in scripts, and the modules are
> responsible for building them as needed. Although it is unclear to me if this is
> really necessary, especially considering that modules put these bits back as
> soon as they compile. If we are not generating an sstate package, I suspect we
> can ignore these.
>
> Please try this with your modules and let me know how it does. I tried to take
> non linux-yocto kernel recipes into account, but I have only tested with
> linux-yocto and the hello-mod recipe so far.
>
> V2: o Address 000 perm quilt files (don't copy .pc dir)
> o Clear linux-yocto meta dir from sysroots
>
> Signed-off-by: Darren Hart <dvhart at linux.intel.com>
This one works beautifully, so:
Acked-by: Koen Kooi <koen at dominion.thruhere.net>
More information about the Openembedded-core
mailing list