From: Nicholas Mc Guire <der.herr@hofr.at>
To: Michal Marek <mmarek@suse.cz>
Cc: Jonathan Corbet <corbet@lwn.net>,
Nicholas Mc Guire <hofrat@osadl.org>,
linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kbuild: add documentation of KBUILD_BUILD_VERSION
Date: Sun, 12 Apr 2015 06:08:54 +0200 [thread overview]
Message-ID: <20150412040853.GA22517@opentech.at> (raw)
In-Reply-To: <55297BE2.60401@suse.cz>
On Sat, 11 Apr 2015, Michal Marek wrote:
> Dne 11.4.2015 v 15:20 Nicholas Mc Guire napsal(a):
> > On Sat, 11 Apr 2015, Jonathan Corbet wrote:
> >
> >> On Sun, 5 Apr 2015 08:44:28 +0200
> >> Nicholas Mc Guire <hofrat@osadl.org> wrote:
> >>
> >>> KBUILD_BUILD_VERSION is currently not documented but it is
> >>> needed when rebuilding a kernel that should result in the identical
> >>> binary. This is a brief documentation of KBUILD_BUILD_VERSION.
> >>
> >> Can we add something like the above to the document itself so that
> >> readers have an idea of why they might want to tweak this?
> >>
> >> Either way, I can take it in the docs tree if that's best..Michal?
> >>
> > I thought of that but it would be inconsistent as all other descriptions
> > here are only the function not the use.
>
> Most of the entries in this file predate efforts at deterministic
> builds, so I'd prefer usefulness over consistency here :-).
>
>
> > I did not find a file where
> > the problem of identical rebuild would really fit.
>
> ... unless, of course, you want to start a new file covering this topic.
> Because it's not just the few override variables, but also some options
> have to be turned off (I remember CONFIG_GCOV_KERNEL) and the paths must
> be the same, or relative paths must be used.
>
The identical path really only should be needed for GCOV as it compiles
path info into the binary - are you aware of any other cnfig option that
would need the same path ?
It could be in a short document but it could also just be placed right
under the descriptions of the relevant variables - something like:
Use of KBUILD_BUILD_{TIMESTAMP,VERSION,USER,HOST}
--------------------------------------------------
When the kernel is built, Kbuild stores the build timestamp, version, user
and hostname in include/generated/compile.h. By default this information
is extracted from the build-environment on every build. To override this
behavior and rebuild an identical binary kernel, given a running kernel,
the original compile time information needs to be passed to Kbuild.
Prerequisites:
* Original kernel config available (e.g extract it from /proc/config.gz)
* Identical source tree
* Identical toolchain
* Same source path if building with CONFIG_GCOV_KERNEL
* Module signature (CONFIG_MODULE_SIG) must be disabled
The build process for rebuilding the identical binary kernel can extract the
remaining necessary information from dmesg and set the Kbuild and make env:
from the boot log or dmesg in the running system:
[ 0.000000] Linux version 4.0.0-rc6-sil2 (hofrat@debian) (gcc version 4.7.2
(Debian 4.7.2-5) ) #0 SMP Mon Apr 6 01:49:56 EDT 2015
^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
KBUILD_BUILD_VERSION---' |
KBUILD_BUILD_TIMESTAMP---------------'
$ export KBUILD_BUILD_VERSION=0
$ export KBUILD_BUILD_TIMESTAMP="Mon Apr 6 01:49:56 EDT 2015"
$ export KBUILD_BUILD_USER=hofrat
$ export KBUILD_BUILD_HOST=debian
$ git reset --hard v4.0-rc6
$ zcat /proc/config.gz > .config
$ make oldconfig
$ make -j 8 EXTRAVERSION=-rc6-sil2
probably not quite sufficient yet - but atleast for
defconfigs and a few other trials it worked for me.
If that makes sense to cleanup I'll try to figure out what
other config options could cause problems and submit it
as a patch to kbuild.txt
thx!
hofrat
next prev parent reply other threads:[~2015-04-12 4:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-05 6:44 [PATCH] kbuild: add documentation of KBUILD_BUILD_VERSION Nicholas Mc Guire
2015-04-11 13:15 ` Jonathan Corbet
2015-04-11 13:20 ` Nicholas Mc Guire
2015-04-11 19:54 ` Michal Marek
2015-04-12 4:08 ` Nicholas Mc Guire [this message]
2015-04-13 15:06 ` Michal Marek
2015-04-16 7:22 ` Nicholas Mc Guire
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=20150412040853.GA22517@opentech.at \
--to=der.herr@hofr.at \
--cc=corbet@lwn.net \
--cc=hofrat@osadl.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
/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.