From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mike Looijmans <mike.looijmans@topic.nl>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: Changing external kernel module results in rebuild of whole kernel
Date: Wed, 06 May 2015 13:35:31 +0100 [thread overview]
Message-ID: <1430915731.8074.34.camel@linuxfoundation.org> (raw)
In-Reply-To: <5549B621.4060008@topic.nl>
On Wed, 2015-05-06 at 08:35 +0200, Mike Looijmans wrote:
> Something in recent OE-core triggered a weird dependency "backfire".
>
> If I change a recipe for a kernel module (a bb recipe that does "inherit
> module") this will trigger a rebuild of the whole kernel.
>
> This turns the 5-second job of just updating a single module into a several
> minute workout for the build machine, and then causes boards to re-write the
> kernel into flash needlessly when upgrading.
>
> I now see this on all projects using OE-core master. I can't really pin what
> caused it though. Anyone else seen this?
I have a suspicion this may be as a result of the changed kernel build
process in 1.8.
The idea there is that the modules depend on the kernel source and
rather than taring up and then extracting a large (GB) sized sstate
object, we just extract the original kernel source.
So is the kernel really rebuilding, or, is it just extracting source for
the kernel to build against? I noticed rm_work in your other post and
this may also be some bad interaction between rm_work and the kernel
build process changes.
Cheers,
Richard
next prev parent reply other threads:[~2015-05-06 12:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 6:35 Changing external kernel module results in rebuild of whole kernel Mike Looijmans
2015-05-06 10:35 ` Burton, Ross
2015-05-06 12:12 ` Mike Looijmans
2015-05-06 12:19 ` Mike Looijmans
2015-05-06 12:35 ` Richard Purdie [this message]
2015-05-06 12:41 ` Mike Looijmans
2015-05-12 6:01 ` Mike Looijmans
2015-05-13 10:33 ` Richard Purdie
2015-05-13 15:44 ` Richard Purdie
2015-05-13 20:37 ` Bruce Ashfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1430915731.8074.34.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=mike.looijmans@topic.nl \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox