From: Michal Marek <mmarek@suse.cz>
To: Nicholas Mc Guire <der.herr@hofr.at>
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: Mon, 13 Apr 2015 17:06:56 +0200 [thread overview]
Message-ID: <552BDB90.6040507@suse.cz> (raw)
In-Reply-To: <20150412040853.GA22517@opentech.at>
On 2015-04-12 06:08, Nicholas Mc Guire wrote:
> 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 ?
The paths appear in BUG() messages if you are using O=<path>. This can
be solver by either not using O= or using O=<subdir>, in which case
kbuild uses '..' as path to the srctree.
IIRC the problem with GCOV was that gcc was adding a randomly named
symbol to each object file.
> 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
I think that only MODULE_SIG_ALL is problematic, the signature checking
code itself is OK.
> 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
Michal
next prev parent reply other threads:[~2015-04-13 15:07 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
2015-04-13 15:06 ` Michal Marek [this message]
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=552BDB90.6040507@suse.cz \
--to=mmarek@suse.cz \
--cc=corbet@lwn.net \
--cc=der.herr@hofr.at \
--cc=hofrat@osadl.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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