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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.