We already have this information available during the build process.
This information is output in the first line of the boot log during the
boot process.
Unfortunately, this information is only readbale humans when
they look at the first line of the boolog. In order for this information
to be further processed by the machine and other userland services,
it should be separately readable as epoch date in the proc directory.
Signed-off-by: Florian Eckert <[email protected]>
---
fs/proc/Makefile | 1 +
fs/proc/compile_time.c | 20 ++++++++++++++++++++
scripts/mkcompile_h | 5 ++++-
3 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 fs/proc/compile_time.c
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index bd08616ed8ba..ee61a8c2c840 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -23,6 +23,7 @@ proc-y += stat.o
proc-y += uptime.o
proc-y += util.o
proc-y += version.o
+proc-y += compile_time.o
proc-y += softirqs.o
proc-y += namespaces.o
proc-y += self.o
diff --git a/fs/proc/compile_time.c b/fs/proc/compile_time.c
new file mode 100644
index 000000000000..4cf659d3c28c
--- /dev/null
+++ b/fs/proc/compile_time.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <generated/compile.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
+
+static int compile_time_proc_show(struct seq_file *m, void *v)
+{
+ seq_printf(m, "%s\n", LINUX_COMPILE_EPOCH);
+ return 0;
+}
+
+static int __init proc_compile_time_init(void)
+{
+ proc_create_single("compile_time", 0, NULL, compile_time_proc_show);
+ return 0;
+}
+
+fs_initcall(proc_compile_time_init);
diff --git a/scripts/mkcompile_h b/scripts/mkcompile_h
index ca40a5258c87..d0e927602276 100755
--- a/scripts/mkcompile_h
+++ b/scripts/mkcompile_h
@@ -24,8 +24,10 @@ else
fi
if [ -z "$KBUILD_BUILD_TIMESTAMP" ]; then
- TIMESTAMP=`date`
+ LINUX_COMPILE_EPOCH=$(date +%s)
+ TIMESTAMP=$(date -d "@$LINUX_COMPILE_EPOCH")
else
+ LINUX_COMPILE_EPOCH=$(date -d "$KBUILD_BUILD_TIMESTAMP" +%s)
TIMESTAMP=$KBUILD_BUILD_TIMESTAMP
fi
if test -z "$KBUILD_BUILD_USER"; then
@@ -64,6 +66,7 @@ UTS_VERSION="$(echo $UTS_VERSION $CONFIG_FLAGS $TIMESTAMP | cut -b -$UTS_LEN)"
echo \#define UTS_VERSION \"$UTS_VERSION\"
+ printf '#define LINUX_COMPILE_EPOCH "%s"\n' "$LINUX_COMPILE_EPOCH"
printf '#define LINUX_COMPILE_BY "%s"\n' "$LINUX_COMPILE_BY"
echo \#define LINUX_COMPILE_HOST \"$LINUX_COMPILE_HOST\"
--
2.30.2
Hello Masahiro,
thanks for your feedback.
> https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/
> lands, nobody cannot reference KBUILD_BUILD_TIMESTAMP,
> then this whack-a-mole game will end.
I was not aware of that problem. Thanks for the link.
I understood that this is a bad idea to create the timestamp for proc
like this!
But how does it look in principle to offer the build timestamp in proc
for reading?
You have only made your point about creating the timestamp but not about
reading it out via the proc directory.
So far the timestamp is only readable as a string via dmesg.
Best regards
Florian
On Mon, Sep 12, 2022 at 6:42 PM Florian Eckert <[email protected]> wrote:
>
> Hello Masahiro,
>
> thanks for your feedback.
>
> > https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/
> > lands, nobody cannot reference KBUILD_BUILD_TIMESTAMP,
> > then this whack-a-mole game will end.
>
> I was not aware of that problem. Thanks for the link.
>
> I understood that this is a bad idea to create the timestamp for proc
> like this!
> But how does it look in principle to offer the build timestamp in proc
> for reading?
> You have only made your point about creating the timestamp but not about
> reading it out via the proc directory.
>
> So far the timestamp is only readable as a string via dmesg.
init/version.c is the only file that can depend on the output of
the 'date' command.
You can follow what 'linux_proc_banner' does.
Define it in init/version.c, and declare it somewhere in a header file.
> Best regards
>
> Florian
--
Best Regards
Masahiro Yamada