All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 16 Apr 2015 09:22:58 +0200	[thread overview]
Message-ID: <20150416072258.GD18186@opentech.at> (raw)
In-Reply-To: <552BDB90.6040507@suse.cz>

On Mon, 13 Apr 2015, Michal Marek wrote:

> 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.
>

well it also simply compiles the absolute path into the binary
so that is in the checksum.
 
> 
> > 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.
>

thanks - will check that - not sure if I had _SIG AND _ALL on while testing

thanks for the notes - running a randbuild script to see if this holds or not
should give atleast some level of confidence that the
exeptions are complete.

thx!
hofrat 

      reply	other threads:[~2015-04-16  7:23 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
2015-04-16  7:22           ` Nicholas Mc Guire [this message]

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=20150416072258.GD18186@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.