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@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html