Chen Qi <[email protected]> escreveu no dia quinta, 17/11/2022 à(s)
04:12:

> Currently, the KERNEL_DEBUG_TIMESTAMPS is not working as expected
> at rebuild. That is, even if we set it to "1", the kernel build time
> is not changed. The problem could be reproduced by the following steps.
>   1. bitbake core-image-minimal; start image and check `uname -a` output.
>   2. set in local.conf: KERNEL_DEBUG_TIMESTAMPS = "1"
>   3. bitbake core-image-minimal; start image and check `uname -a` output.
>
> It's expected that after enabling KERNEL_DEBUG_TIMESTAMPS, the kernel
> build time will be set to current date. But it's not. This is because
> the compile.h was not re-generated when do_compile task was re-executed.
>
> In mkcompile_h, we have:
> """
>  # Only replace the real compile.h if the new one is different,
>  # in order to preserve the timestamp and avoid unnecessary
>  # recompilations.
>  # We don't consider the file changed if only the date/time changed,
>  # unless KBUILD_BUILD_TIMESTAMP was explicitly set (e.g. for
>  # reproducible builds with that value referring to a commit timestamp).
>  # A kernel config change will increase the generation number, thus
>  # causing compile.h to be updated (including date/time) due to the
>  # changed comment in the
>  # first line.
> """
> It has made it very clear that it will not be re-generated unless
> we have KBUILD_BUILD_TIMESTAMP set explicitly. So we set this variable
> explicitly in do_compile to fix this issue.
>
> Signed-off-by: Chen Qi <[email protected]>
> ---
>  meta/classes-recipe/kernel.bbclass | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> index 3834a42fb9..3f6b40907f 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -367,6 +367,10 @@ kernel_do_compile() {
>                 export KBUILD_BUILD_TIMESTAMP="$ts"
>                 export KCONFIG_NOTIMESTAMP=1
>                 bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
> +       else
> +               ts=`LC_ALL=C date`
> +               export KBUILD_BUILD_TIMESTAMP="$ts"
> +               bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
>         fi
>         # The $use_alternate_initrd is only set from
>         # do_bundle_initramfs() This variable is specifically for the
> @@ -412,6 +416,10 @@ do_compile_kernelmodules() {
>                 export KBUILD_BUILD_TIMESTAMP="$ts"
>                 export KCONFIG_NOTIMESTAMP=1
>                 bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
> +       else
> +               ts=`LC_ALL=C date`
> +               export KBUILD_BUILD_TIMESTAMP="$ts"
> +               bbnote "KBUILD_BUILD_TIMESTAMP: $ts"
>         fi
>         if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
>                 oe_runmake -C ${B} ${PARALLEL_MAKE} modules
> ${KERNEL_EXTRA_ARGS}
> --
> 2.17.1
>

Hi Chen,

I think this only works on the first time you run it and after that if the
kernel can be taken from the sstate-cache this timestamp will be bypassed.
To generate a new timestamp you need to invalidate the stamp and run the
task again with:

bitbake virtual/linux -C do_compile

Another possible issue is this will make this task indeterministic (not
reproducible) as it uses the command 'date' that generates a
different output in each run.

IMO the bitbake DATETIME is better and it is deterministic:

export KBUILD_BUILD_TIMESTAMP="$DATETIME"

This also maybe introduces a new variable dependency exclusion on the tasks
that uses this variable:

kernel_do_compile[vardepsexclude] += DATETIME
do_compile_kernelmodules[vardepsexclude] += DATETIME

Jose


>
> 
>
>

-- 
Best regards,

José Quaresma
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#173453): 
https://lists.openembedded.org/g/openembedded-core/message/173453
Mute This Topic: https://lists.openembedded.org/mt/95083712/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to