From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Holger Hans Peter Freyther <holger@freyther.de>
Cc: poky@yoctoproject.org
Subject: Re: kernel.release being regenerated
Date: Wed, 11 Feb 2015 09:10:57 +0000 [thread overview]
Message-ID: <1423645857.20217.56.camel@linuxfoundation.org> (raw)
In-Reply-To: <20150211082703.GA3213@xiaoyu.lan>
On Wed, 2015-02-11 at 09:27 +0100, Holger Hans Peter Freyther wrote:
> On Tue, Feb 10, 2015 at 10:51:26PM +0000, Richard Purdie wrote:
> > Hi Holger,
>
> Hi Richard,
>
> > The fact the kernel.release is being recreated suggests something in the
> > configuration is changing (different environment or commandline
> > options?) or that there is a problem in your kernel to do with the
> > Makefiles and the dependencies of the kernel.release file.
>
> This issue should be seen by everyone but the race is pretty small.
> do_shared_workdir must run shortly after compilemodules has started
> and removed the file but didn't create a new one. This is the kind
> of race I am more likely to hit than the average population. The
> "configuration is changing" part looks like a red herring to me.
> From looking at the Makefile I see a FORCE as dependency of the
> kernel.release rule. With my 3.10er kernel (and it doesn't look
> like we have patched the Makefile) the dependency chain is like
> this:
>
> init -> prepare -> prepare0 .. -> prepare3 -> kernel.release -> FORCE
>
> This means that on any target being executed the kernel.release
> will be re-created. I think the only stable way would be to have
> do_compile copy the kernel.release to another place and have the
> copying task pick this file from another place.
This does sound like a flaw in how we're copying the file if it is
regenerated on each execution of make within the kernel build.
What puzzles me is that the use of kernel.release isn't new, the
previous do_install code used to do this and technically would have
raced with do_compilemodules too. So was it just bad luck you started
hitting this now?
(http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/kernel.bbclass?id=92725ad46f4d331bea6a2fa65964158d78a7add8)
As you say, if this really is getting regenerated as you describe, we'll
have to store a safe copy in the tree.
Cheers,
Richard
next prev parent reply other threads:[~2015-02-11 9:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-10 18:43 kernel.release being regenerated Holger Hans Peter Freyther
2015-02-10 22:51 ` Richard Purdie
2015-02-11 4:42 ` Bruce Ashfield
2015-02-11 8:27 ` Holger Hans Peter Freyther
2015-02-11 9:10 ` Richard Purdie [this message]
2015-02-11 17:32 ` Bruce Ashfield
2015-02-11 19:35 ` Holger Hans Peter Freyther
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=1423645857.20217.56.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=holger@freyther.de \
--cc=poky@yoctoproject.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.