All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: acme@kernel.org, andrii.nakryiko@gmail.com,
	dwarves@vger.kernel.org, jolsa@kernel.org, williams@redhat.com,
	kcarcia@redhat.com, dxu@dxuuu.xyz, eddyz87@gmail.com
Subject: Re: [PATCH dwarves] pahole: enable --reproducible_build when SOURCE_DATE_EPOCH is set
Date: Sat, 29 Jun 2024 04:44:48 +0900	[thread overview]
Message-ID: <Zn8SsFuSAG2qPgzC@codewreck.org> (raw)
In-Reply-To: <1213004a-c75a-4882-bd51-47d458c67e04@oracle.com>

Alan Maguire wrote on Fri, Jun 28, 2024 at 09:31:17AM +0100:
> FWIW I verified that with the above change, and
> 
> export KBUILD_BUILD_TIMESTAMP=$(date -I)
> 
> ...the feature flag is added to pahole and as a result we get
> reproducible BTF in vmlinux; .btf.vmlinux.bin.o is identical across
> multiple kernel builds.

Sorry for the lack of reply, I didn't have time to test until now, and I
have no idea how to override the kernel config in nixos so the checking
build through nix build took all night.
I've now also confirmed this works including for modules BTF & linux
"package" build on nixos on master.

However from there I built a random kernel module and have also
confirmed they don't set KBUILD_BUILD_TIMESTAMP for external modules --
from a quick look it's not part of the default flags defined as
buildFlags here[1] because each modules' SOURCE_DATE_EPOCH isn't
available at this level (and I have no idea how to call a command at
this level), the configurePhase where it's set only applies to the
kernel itself and not the gazillion of modules.
[1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/manual-config.nix

Add to that that nixos is supporting a dozen of kernels -- all mainlines
stable versions but also a dozen of variants (rt, whatever xanmod and
zen are, and if you look for things like mobile-nixos you'll also get
much older and not update sunxi and other embedded trees) I definitely
won't put the effort to backport equivalent patches to all these kernels


I wanted the patch for alpine as well but I honestly don't have the time
to do the same confirmation work there; if they have any external
modules I don't see the flag being set either, at least they don't have
so many kernels.
(but unlike nixos the kernel build "framework" code isn't shared and I
know of at least one out of tree embedded kernel that doesn't set
KBUILD_BUILD_TIMESTAMP and only has SOURCE_DATE_EPOCH...)


So:
 - in theory, sure; this patch works. I say we can do this independantly
of any other effort. The propere way of setting reproducible build in
the kernel is not SOURCE_DATE_EPOCH but KBUILD_BUILD_TIMESTAMP and
handling it at kernel makefile level is sound.
 - in practice, (nixos hat) some modules won't set it but will only have
SOURCE_DATE_EPOCH available, and there are trees that won't be updated
for years (and that's being optimistic), so our local patch in pahole is
here to stay for a while and the benefits far outweight the rebasing
work.
 - (alpine hat) alpine doesn't seem to care as much about
reproducibility (the nixos patch wasn't in and nobody complained so far),
undecided at this point. Makefile.btf patch is probably good enough, but
since I'm maintaining the patch anyway it's no extra work to add it
there, undecided at this point.


Thanks,
-- 
Dominique Martinet | Asmadeus

  parent reply	other threads:[~2024-06-28 19:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-26  3:22 [PATCH dwarves] pahole: enable --reproducible_build when SOURCE_DATE_EPOCH is set Dominique Martinet
2024-06-26 14:29 ` Alan Maguire
2024-06-26 23:01   ` Dominique Martinet
2024-06-27 17:25     ` Alan Maguire
2024-06-28  8:31       ` Alan Maguire
2024-06-28 13:59         ` Arnaldo Carvalho de Melo
2024-06-28 19:44         ` Dominique Martinet [this message]
2024-07-01 16:44           ` Alan Maguire
2024-07-01 23:35             ` Dominique Martinet

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=Zn8SsFuSAG2qPgzC@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=acme@kernel.org \
    --cc=alan.maguire@oracle.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=dwarves@vger.kernel.org \
    --cc=dxu@dxuuu.xyz \
    --cc=eddyz87@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kcarcia@redhat.com \
    --cc=williams@redhat.com \
    /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.