Make kernel build deterministic

Timestamps in file data are useless and there is already one in .config

Signed-off-by Michal Marek <[email protected]>

---
 scripts/kconfig/confdata.c |    8 ++------

 1 files changed, 2 insertions(+), 6 deletions(-)

scripts/kconfig/confdata.c +0 -2

index 61c35bf..834eecb 100644
@@ -784,7 +784,6 @@ int conf_write_autoconf(void)
        const char *str;
        const char *name;
        FILE *out, *tristate, *out_h;
-       time_t now;
        int i;
 
        sym_clear_all_valid();

@@ -811,22 +810,19 @@ int conf_write_autoconf(void)
                return 1;
        }
 
-       time(&now);

       fprintf(out, "#\n"
                    "# Automatically generated make config: don't edit\n" "# %s\n"
-                    "# %s"
                    "#\n",
-                    rootmenu.prompt->text, ctime(&now));
+                    rootmenu.prompt->text); fprintf(tristate, "#\n"
                         "# Automatically generated - do not edit\n" "\n");
       fprintf(out_h, "/*\n"
                      " * Automatically generated C config: don't edit\n" " * %s\n"
-                      " * %s"
                      " */\n",
-                      rootmenu.prompt->text, ctime(&now));
+                      rootmenu.prompt->text);

       for_all_symbols(i, sym) {
               sym_calc_value(sym);
--
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 2 lines · Michal Marek

Timestamps in file data are useless and there is already one in .config

hum, shouldn't this be tunable via KCONFIG_NOTIMESTAMP ? This might be useful to know when the file was generated, independently of the .config, as conf_write() and conf_write_autoconf() are independent from one another.

Quoted 5 lines · Arnaud Lacombe

Hi,

Quoted 2 lines · Michal Marek

Timestamps in file data are useless and there is already one in .config

Quoted 4 lines

hum, shouldn't this be tunable via KCONFIG_NOTIMESTAMP ? This might be useful to know when the file was generated, independently of the .config, as conf_write() and conf_write_autoconf() are independent from one another.

Yeah, but ls -l include/generated/autoconf.h will tell you the same, won't it?

Hi,

Quoted 11 lines · Michal Marek

Quoted 9 lines · Arnaud Lacombe

Hi,

Quoted 2 lines · Michal Marek

Timestamps in file data are useless and there is already one in .config

hum, shouldn't this be tunable via KCONFIG_NOTIMESTAMP ? This might be useful to know when the file was generated, independently of the .config, as conf_write() and conf_write_autoconf() are independent from one another.

Quoted 3 lines

Yeah, but ls -l include/generated/autoconf.h will tell you the same, won't it?

Not if the file is spread to other machine/fs. Not that I care much though, but for consistency, either KCONFIG_NOTIMESTAMP is honored in every places where timestamps are used, or it should be killed altogether.

Timestamps in file data are useless and there is already one in .config

Signed-off-by Michal Marek <[email protected]>

---
 scripts/kconfig/confdata.c |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

The timestamps recorded in the .gz files add no value.

Signed-off-by Michal Marek <[email protected]>

---
 scripts/Makefile.lib          |    2 +-
 scripts/gen_initramfs_list.sh |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

Signed-off-by Michal Marek <[email protected]>

---
 scripts/Makefile.build |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Signed-off-by Michal Marek <[email protected]>

---
 scripts/mkcompile_h |   16 ++--------------
 1 files changed, 2 insertions(+), 14 deletions(-)

scripts/mkcompile_h UTS_TRUNCATE="cut -b -$UTS_LEN" · line 77

Quoted 4 lines

scripts/mkcompile_h +2 -2

-  echo \#define LINUX_COMPILE_BY \"`whoami`\"
-  echo \#define LINUX_COMPILE_HOST \"`hostname | $UTS_TRUNCATE`\"
+  echo \#define LINUX_COMPILE_BY \"`echo $KBUILD_BUILD_USER | $UTS_TRUNCATE`\"
+  echo \#define LINUX_COMPILE_HOST \"`echo $KBUILD_BUILD_HOST | $UTS_TRUNCATE`\"

Shouldn't these be the variables defined above otherwise we get empty LINUX_COMPILE_{BY,HOST} in the case the corresponding environment variable is unset.

Documentation/kbuild/kbuild.txt to be included in the databases, separated by blank space. E.g.: · line 200

Quoted 6 lines · Michal Marek

Make it possible to override the user@host string displayed during boot and in /proc/version by the environment variables KBUILD_BUILD_USER and KBUILD_BUILD_HOST.

Documentation/kbuild/kbuild.txt +2 -0

+
+KBUILD_BUILD_TIMESTAMP

Changelog section doesn't match actual patch. Other than that, I'm OK on this.

Quoted 9 lines · On 12.4.2011 05:25, [email protected] wrote:

Documentation/kbuild/kbuild.txt to be included in the databases, separated by blank space. E.g.: · line 200

Quoted 6 lines · Michal Marek

Make it possible to override the user@host string displayed during boot and in /proc/version by the environment variables KBUILD_BUILD_USER and KBUILD_BUILD_HOST.

Documentation/kbuild/kbuild.txt +2 -0

+
+KBUILD_BUILD_TIMESTAMP

Changelog section doesn't match actual patch. Other than that, I'm OK on this.

I changed it to

Make it possible to override the user@host string displayed during boot and in /proc/version by the environment variables KBUILD_BUILD_USER and KBUILD_BUILD_HOST. Several distributions patch scripts/mkcompile_h to achieve this, so let's provide an official way. Also, document the KBUILD_BUILD_TIMESTAMP variable while at it.

gen_init_cpio uses the current time for symlinks, special files and directories.

Make it possible to override this with the

KBUILD_BUILD_TIMESTAMP variable for reproducible builds.

Signed-off-by Michal Marek <[email protected]>

---
scripts/gen_initramfs_list.sh | 4 ++++

 usr/gen_init_cpio.c           |   17 +++++++++++------
 2 files changed, 15 insertions(+), 6 deletions(-)

scripts/gen_initramfs_list.sh +0 -0

usr/gen_init_cpio.c +0 -0

index 7f06884..11f604d 100644

usr/gen_init_cpio.c +1 -0

@@ -529,6 +527,7 @@ int main (int argc, char *argv[])
 	char *args, *type;
 	int ec = 0;
 	int line_nr = 0;
+	const char *env;
 
 	if (2 != argc) {
 		usage(argv[0]);

Quoted 3 lines

gen_init_cpio uses the current time for symlinks, special files and directories.

gen_init_cpio gets the current time and uses it for each symlink, special file, and directory.

Grab the current time once, and ...

Quoted 1 line

Make it possible to override this with the

(s/this/it/)

Quoted 2 lines

KBUILD_BUILD_TIMESTAMP variable for reproducible builds.

usr/gen_init_cpio.c int main (int argc, char *argv[]) · line 551

Quoted 6 lines

usr/gen_init_cpio.c +6 -0

+	env = getenv("CPIO_TIMESTAMP");
+	if (env)
+		default_mtime = atol(env);
+	if (!default_mtime)
+		default_mtime = time(NULL);
+

Please pass it via an explicit flag in argv instead of magic env variables.

The other current use of the environment (the expansion of variables in the location name) is via explicit reference in the input file.

Also, please use strol and check that the whole string is consumed.

gen_init_cpio gets the current time and uses it for each symlink, special file, and directory. Grab the current time once and make it possible to override it with the KBUILD_BUILD_TIMESTAMP variable for reproducible builds.

Signed-off-by Michal Marek <[email protected]>

---
 Documentation/kbuild/kbuild.txt |    3 +-
 scripts/gen_initramfs_list.sh   |    9 ++++++-
 usr/gen_init_cpio.c             |   53 +++++++++++++++++++++++++++++---------
 3 files changed, 50 insertions(+), 15 deletions(-)

Cc Thomas Gleixner <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc "H. Peter Anvin" <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 arch/x86/boot/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

arch/x86/boot/Makefile +0 -0

index f7cb086..7a70c60 100644

Quoted 9 lines

arch/x86/boot/Makefile +1 -1

@@ -13,7 +13,7 @@
 # This can be either FLOPPY, CURRENT, /dev/xxxx or empty, in which case
 # the default of FLOPPY is used by 'build'.
 
-ROOT_DEV	:= CURRENT
+ROOT_DEV	?= CURRENT
 

arch/x86/boot/Makefile line 19

Quoted 2 lines

arch/x86/boot/Makefile +0 -0

 # If you want to preset the SVGA mode, uncomment the next line and
 # set SVGA_MODE to whatever number you want.

Is this a good thing? As far as I understand ?= it may mean picking something up from the outside environment.

Since ROOT_DEV has been obsolete for 15 years or more, this would seem to be a needless new error mode.

Quoted 15 lines · H. Peter Anvin

arch/x86/boot/Makefile line 19

Quoted 11 lines

arch/x86/boot/Makefile +1 -1

@@ -13,7 +13,7 @@
 # This can be either FLOPPY, CURRENT, /dev/xxxx or empty, in which case
 # the default of FLOPPY is used by 'build'.
 
-ROOT_DEV	:= CURRENT
+ROOT_DEV	?= CURRENT
 
 # If you want to preset the SVGA mode, uncomment the next line and
 # set SVGA_MODE to whatever number you want.

Is this a good thing? As far as I understand ?= it may mean picking something up from the outside environment.

Quoted 2 lines

Since ROOT_DEV has been obsolete for 15 years or more, this would seem to be a needless new error mode.

So can we just set the default root device to (0, 0)?

Like this?

Subject: [PATCH] x86: Do not set the rood_dev field in bzImage

Does the default of FLOPPY still get used after this patch, or is this a stale comment?

Also, I sort of expected to see more code removed that *used* the no-longer-passed value of ROOT_DEV.

Like this?

Subject: [PATCH] x86: Do not set the rood_dev field in bzImage

This has been obsoleted by the root= commandline for several years. People who still depend on this will surely have a copy of the rdev command around, the rest of the world gets rid of another piece of buildhost-dependent data in the build.

Subject: [PATCH] x86: Do not set the rood_dev field in bzImage

This has been obsoleted by the root= commandline for several years. People who still depend on this will surely have a copy of the rdev command around, the rest of the world gets rid of another piece of buildhost-dependent data in the build.

Cc Thomas Gleixner <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc "H. Peter Anvin" <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 arch/x86/boot/Makefile |    9 +--------
 1 files changed, 1 insertions(+), 8 deletions(-)

arch/x86/boot/Makefile +0 -6

index f7cb086..95365a8 100644
@@ -9,12 +9,6 @@
 # Changed by many, many contributors over the years.
 #
 
-# ROOT_DEV specifies the default root-device when making the image.
-# This can be either FLOPPY, CURRENT, /dev/xxxx or empty, in which case
-# the default of FLOPPY is used by 'build'.
-
-ROOT_DEV	:= CURRENT
-
 # If you want to preset the SVGA mode, uncomment the next line and
 # set SVGA_MODE to whatever number you want.
 # Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode.

Quoted 1 line · Michal Marek

Subject: [PATCH] x86: Do not set the rood_dev field in bzImage

I'm not familiar with the rdev command. I assume it allows one to manipulate the two rootdev bytes in a kernel image.

arch/x86/boot/tools/build.c +4 -29

@@ -130,7 +130,7 @@ static void die(const char * str, ...)
 
  static void usage(void)
  {
-	die("Usage: build setup system [rootdev] [>  image]");
+	die("Usage: build setup system [>  image]");
  }
 
  int main(int argc, char ** argv)

@@ -138,39 +138,14 @@ int main(int argc, char ** argv)
  	unsigned int i, sz, setup_sectors;
  	int c;
  	u32 sys_size;
-	u8 major_root, minor_root;
  	struct stat sb;
  	FILE *file;
  	int fd;
  	void *kernel;
  	u32 crc = 0xffffffffUL;
 
-	if ((argc<  3) || (argc>  4))
+	if (argc != 3)
  		usage();
-	if (argc>  3) {
-		if (!strcmp(argv[3], "CURRENT")) {
-			if (stat("/",&sb)) {
-				perror("/");
-				die("Couldn't stat /");
-			}
-			major_root = major(sb.st_dev);
-			minor_root = minor(sb.st_dev);
-		} else if (strcmp(argv[3], "FLOPPY")) {
-			if (stat(argv[3],&sb)) {
-				perror(argv[3]);
-				die("Couldn't stat root device.");
-			}
-			major_root = major(sb.st_rdev);
-			minor_root = minor(sb.st_rdev);
-		} else {
-			major_root = 0;
-			minor_root = 0;
-		}
-	} else {
-		major_root = DEFAULT_MAJOR_ROOT;
-		minor_root = DEFAULT_MINOR_ROOT;
-	}
-	fprintf(stderr, "Root device is (%d, %d)\n", major_root, minor_root);
 
  	/* Copy the setup code */
  	file = fopen(argv[1], "r");

@@ -193,8 +168,8 @@ int main(int argc, char ** argv)
  	memset(buf+c, 0, i-c);
 
  	/* Set the default root device */
-	buf[508] = minor_root;
-	buf[509] = major_root;
+	buf[508] = DEFAULT_MINOR_ROOT;
+	buf[509] = DEFAULT_MAJOR_ROOT;
 
  	fprintf(stderr, "Setup is %d bytes (padded to %d bytes).\n", c, i);
 

That makes sense. Will you send it as a proper patch or should I fold it into my patch?

This has been obsoleted by the root= commandline for several years. People who still depend on this will surely have a copy of the rdev command around, the rest of the world gets rid of another piece of buildhost-dependent data in the build. Thanks to Paul Bolle for the build.c cleanup.

Cc Thomas Gleixner<[email protected]>

Cc Ingo Molnar<[email protected]>

Cc "H. Peter Anvin"<[email protected]>

Cc [email protected]

Cc Paul Bolle<[email protected]>

Signed-off-by Michal Marek<[email protected]>

arch/x86/boot/Makefile +1 -8

index f7cb086..95365a8 100644
@@ -9,12 +9,6 @@
  # Changed by many, many contributors over the years.
  #
 
-# ROOT_DEV specifies the default root-device when making the image.
-# This can be either FLOPPY, CURRENT, /dev/xxxx or empty, in which case
-# the default of FLOPPY is used by 'build'.
-
-ROOT_DEV	:= CURRENT
-
  # If you want to preset the SVGA mode, uncomment the next line and
  # set SVGA_MODE to whatever number you want.
  # Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode.

@@ -75,8 +69,7 @@ GCOV_PROFILE := n
  $(obj)/bzImage: asflags-y  := $(SVGA_MODE)
 
  quiet_cmd_image = BUILD   $@
-cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
-	$(ROOT_DEV)>  $@
+cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin>  $@
 
  $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
  	$(call if_changed,image)

arch/x86/boot/tools/build.c +4 -30

index ee3a4ea..fdc60a0 100644
@@ -130,7 +130,7 @@ static void die(const char * str, ...)
 
  static void usage(void)
  {
-	die("Usage: build setup system [rootdev] [>  image]");
+	die("Usage: build setup system [>  image]");
  }
 
  int main(int argc, char ** argv)

@@ -138,39 +138,14 @@ int main(int argc, char ** argv)
  	unsigned int i, sz, setup_sectors;
  	int c;
  	u32 sys_size;
-	u8 major_root, minor_root;
  	struct stat sb;
  	FILE *file;
  	int fd;
  	void *kernel;
  	u32 crc = 0xffffffffUL;
 
-	if ((argc<  3) || (argc>  4))
+	if (argc != 3)
  		usage();
-	if (argc>  3) {
-		if (!strcmp(argv[3], "CURRENT")) {
-			if (stat("/",&sb)) {
-				perror("/");
-				die("Couldn't stat /");
-			}
-			major_root = major(sb.st_dev);
-			minor_root = minor(sb.st_dev);
-		} else if (strcmp(argv[3], "FLOPPY")) {
-			if (stat(argv[3],&sb)) {
-				perror(argv[3]);
-				die("Couldn't stat root device.");
-			}
-			major_root = major(sb.st_rdev);
-			minor_root = minor(sb.st_rdev);
-		} else {
-			major_root = 0;
-			minor_root = 0;
-		}
-	} else {
-		major_root = DEFAULT_MAJOR_ROOT;
-		minor_root = DEFAULT_MINOR_ROOT;
-	}
-	fprintf(stderr, "Root device is (%d, %d)\n", major_root, minor_root);
 
  	/* Copy the setup code */
  	file = fopen(argv[1], "r");

@@ -193,8 +168,8 @@ int main(int argc, char ** argv)
  	memset(buf+c, 0, i-c);
 
  	/* Set the default root device */
-	buf[508] = minor_root;
-	buf[509] = major_root;
+	buf[508] = DEFAULT_MINOR_ROOT;
+	buf[509] = DEFAULT_MAJOR_ROOT;
 
  	fprintf(stderr, "Setup is %d bytes (padded to %d bytes).\n", c, i);
 
--

To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 6 lines

This has been obsoleted by the root= commandline for several years. People who still depend on this will surely have a copy of the rdev command around, the rest of the world gets rid of another piece of buildhost-dependent data in the build. Thanks to Paul Bolle for the build.c cleanup.

Quoted 6 lines

Cc Thomas Gleixner<[email protected]>

Cc Ingo Molnar<[email protected]>

Cc "H. Peter Anvin"<[email protected]>

Cc [email protected]

Cc Paul Bolle<[email protected]>

Signed-off-by Michal Marek<[email protected]>

Hi,

Is this patch OK for the tip tree?

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Greg Kroah-Hartman <[email protected]>

Signed-off-by Michal Marek <[email protected]>

---
 drivers/char/cyclades.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Greg Kroah-Hartman <[email protected]>

Signed-off-by Michal Marek <[email protected]>

---
 drivers/char/nozomi.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Armin Schindler <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
drivers/isdn/hardware/eicon/divasfunc.c | 5 ++---

1 files changed, 2 insertions(+), 3 deletions(-)

drivers/isdn/hardware/eicon/divasfunc.c +2 -3

index d36a4c0..0bbee78 100644
@@ -113,9 +113,8 @@ void diva_xdi_didd_remove_adapter(int card)
 static void start_dbg(void)
 {
 	DbgRegister("DIVAS", DRIVERRELEASE_DIVAS, (debugmask) ? debugmask : DBG_DEFAULT);
-	DBG_LOG(("DIVA ISDNXDI BUILD (%s[%s]-%s-%s)",
-		 DIVA_BUILD, diva_xdi_common_code_build, __DATE__,
-		 __TIME__))
+	DBG_LOG(("DIVA ISDNXDI BUILD (%s[%s])",
+		 DIVA_BUILD, diva_xdi_common_code_build))
 }
 
 /*

Signature · 7 lines

1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 3 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

The module can be build separately from the kernel, therefore it can have an own build timestamp.

Quoted 5 lines · Armin Schindler

Quoted 3 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Quoted 2 lines

The module can be build separately from the kernel, therefore it can have an own build timestamp.

[...]

If you want to distribute an out-of-tree version, that's your own business. It shouldn't limit what is done with the in-tree version. Perhaps we could make modpost add a build timestamp to OOT modules, though.

Quoted 10 lines · Ben Hutchings

Quoted 7 lines · Armin Schindler

Quoted 3 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

The module can be build separately from the kernel, therefore it can have an own build timestamp.

[...]

Quoted 4 lines

If you want to distribute an out-of-tree version, that's your own business. It shouldn't limit what is done with the in-tree version. Perhaps we could make modpost add a build timestamp to OOT modules, though.

I know out-of-tree stuff doesn't matter here. But I'm thinking about just doing 'make modules'.

Quoted 3 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

The module can be build separately from the kernel, therefore it can have an own build timestamp.

Quoted 7 lines · Armin Schindler

Quoted 3 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

The module can be build separately from the kernel, therefore it can have an own build timestamp.

If the same code is being built as an out-of-tree module, that's a possibly good reason for a code version variable, but what does the build timestamp actually tell you? If you already know foo_driver.c version 0.814 was buiilt against 2.6.41-rc2, in what cases does it matter if the compile was on Tuesday or Thursday - especially since an 'ls -l foo_driver.ko' will tell you? If it's a matter of "the target .config changed on Wednesday", a build timestamp still doesn't help over 'ls -l'.

Quoted 3 lines

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

The module can be build separately from the kernel, therefore it can have an own build timestamp.

Dne 5.4.2011 17:10, Armin Schindler napsal(a):

Quoted 7 lines · Michal Marek

Quoted 3 lines

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

The module can be build separately from the kernel, therefore it can have an own build timestamp.

So the module timestamp and kernel timestamp vary by a couple of minutes. But is it really a problem?

I don't think so. So is there an
objection against applying this patch?

Quoted 11 lines · Michal Marek

Dne 5.4.2011 17:10, Armin Schindler napsal(a):

Quoted 7 lines · Michal Marek

Quoted 3 lines

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

The module can be build separately from the kernel, therefore it can have an own build timestamp.

So the module timestamp and kernel timestamp vary by a couple of minutes. But is it really a problem?

It could be a lot more than minutes. But it isn't a problem. I just tried to keep the sources in sync with out-of-tree version.

Quoted 2 lines

I don't think so. So is there an
objection against applying this patch?

No objection. Please go ahead with the patch.

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Mauro Carvalho Chehab <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/media/radio/radio-maxiradio.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Mauro Carvalho Chehab <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/media/video/cx231xx/cx231xx-avcore.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Quoted 8 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Thomas Sailer<[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Michal Marek<[email protected]>

Acked-by Thomas Sailer<[email protected]>

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Chuanxiao Dong <[email protected]>

Cc David Woodhouse <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

Quoted 4 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Quoted 4 lines

Cc Chuanxiao Dong <[email protected]>

Cc David Woodhouse <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

Do you want this to got via the MTD tree or you'd rather merge it with the rest of the patches via some other tree? In any case,

Acked-by Artem Bityutskiy <[email protected]>

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Chuanxiao Dong <[email protected]>

Cc David Woodhouse <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/mtd/nand/denali.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Thomas Sailer <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/net/hamradio/hdlcdrv.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

drivers/net/hamradio/hdlcdrv.c +0 -0

index 5b37579..a4a3516 100644

Am 05.04.2011 16:59, schrieb Michal Marek:

Quoted 9 lines

drivers/net/hamradio/hdlcdrv.c +1 -1

@@ -749,7 +749,7 @@ EXPORT_SYMBOL(hdlcdrv_unregister);
 static int __init hdlcdrv_init_driver(void)
 {
 	printk(KERN_INFO "hdlcdrv: (C) 1996-2000 Thomas Sailer HB9JNX/AE4WA\n");
-	printk(KERN_INFO "hdlcdrv: version 0.8 compiled " __TIME__ " " __DATE__ "\n");
+	printk(KERN_INFO "hdlcdrv: version 0.8\n");
 	return 0;

drivers/net/hamradio/hdlcdrv.c EXPORT_SYMBOL(hdlcdrv_unregister); · line 755

Quoted 2 lines

drivers/net/hamradio/hdlcdrv.c +0 -0

 }
 

Its a bit late but i am not a big fan of hard coded version id's. Does GIT provide something like that ? If not
IMHO the line
printk(KERN_INFO "hdlcdrv: version 0.8\n");
can be removed.

Quoted 4 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Quoted 4 lines

Cc Thomas Sailer<[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Michal Marek<[email protected]>

Acked-by Thomas Sailer<[email protected]>

Ok with me

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc "David S. Miller" <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/net/wan/pc300_drv.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

drivers/net/wan/pc300_drv.c +1 -2

index f875cfa..80ae503 100644
@@ -3242,8 +3242,7 @@ static inline void show_version(void)
 	rcsdate++;
 	tmp = strrchr(rcsdate, ' ');
 	*tmp = '\0';
-	printk(KERN_INFO "Cyclades-PC300 driver %s %s (built %s %s)\n", 
-		rcsvers, rcsdate, __DATE__, __TIME__);
+	printk(KERN_INFO "Cyclades-PC300 driver %s %s\n", rcsvers, rcsdate);
 }				/* show_version */
 
 static const struct net_device_ops cpc_netdev_ops = {

Dne 5.4.2011 16:59, Michal Marek napsal(a):

Quoted 10 lines

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc "David S. Miller" <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/net/wan/pc300_drv.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

I don't see the patch in today's linux-next. Does anyone object against me applying it to kbuild-2.6.git?

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Ivo van Doorn <[email protected]>

Cc Gertjan van Wingerde <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/net/wireless/rt2x00/rt2x00debug.c |    1 -

 1 files changed, 0 insertions(+), 1 deletions(-)

drivers/net/wireless/rt2x00/rt2x00debug.c +0 -2

index c92db32..66166ef 100644
@@ -568,7 +568,6 @@ static struct dentry *rt2x00debug_create_file_driver(const char *name,
        blob->data = data;
        data += sprintf(data, "driver:\t%s\n", intf->rt2x00dev->ops->name);
        data += sprintf(data, "version:\t%s\n", DRV_VERSION);
-       data += sprintf(data, "compiled:\t%s %s\n", __DATE__, __TIME__);
        blob->size = strlen(blob->data);
 
        return debugfs_create_blob(name, S_IRUSR, intf->driver_folder, blob);
--

1.7.4.1

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Ivo van Doorn <[email protected]>

Cc Gertjan van Wingerde <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/net/wireless/rt2x00/rt2x00debug.c |    1 -

 1 files changed, 0 insertions(+), 1 deletions(-)

drivers/net/wireless/rt2x00/rt2x00debug.c +0 -2

index c92db32..66166ef 100644
@@ -568,7 +568,6 @@ static struct dentry *rt2x00debug_create_file_driver(const char *name,
        blob->data = data;
        data += sprintf(data, "driver:\t%s\n", intf->rt2x00dev->ops->name);
        data += sprintf(data, "version:\t%s\n", DRV_VERSION);
-       data += sprintf(data, "compiled:\t%s %s\n", __DATE__, __TIME__);
        blob->size = strlen(blob->data);
 
        return debugfs_create_blob(name, S_IRUSR, intf->driver_folder, blob);
--

1.7.4.1

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Arnaud Giersch <[email protected]>

Signed-off-by Michal Marek <[email protected]>

---
 drivers/parport/parport_ip32.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

Quoted 9 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Arnaud Giersch <[email protected]>

Signed-off-by Michal Marek <[email protected]>

---
 drivers/parport/parport_ip32.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

I do not use this module anymore, but anyway...

Acked-by Arnaud Giersch <[email protected]>

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Adaptec OEM Raid Solutions <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/scsi/aacraid/linit.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc "James E.J. Bottomley" <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/scsi/in2000.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc "James E.J. Bottomley" <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/scsi/wd33c93.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Quoted 3 lines · Michal Marek

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

What about drivers built as modules, which may be compiled at a different time than the rest of the kernel?

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Christine Caulfield <[email protected]>

Cc David Teigland <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 fs/dlm/main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

fs/dlm/main.c +1 -1

index b80e0aa..5a59efa 100644
@@ -50,7 +50,7 @@ static int __init init_dlm(void)
 	if (error)
 		goto out_netlink;
 
-	printk("DLM (built %s %s) installed\n", __DATE__, __TIME__);
+	printk("DLM installed\n");
 
 	return 0;
 

Dne 5.4.2011 16:59, Michal Marek napsal(a):

Quoted 11 lines

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Christine Caulfield <[email protected]>

Cc David Teigland <[email protected]>

Cc cluster-devel at redhat.com

Signed-off-by Michal Marek <[email protected]>

---
 fs/dlm/main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Hi,

I don't see this patch in today's linux-next. Any objection against me applying it to the kbuild-2.6.git repository?

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Steven Whitehouse <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 fs/gfs2/main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

fs/gfs2/main.c +1 -1

index 72c31a3..07d057b 100644
@@ -143,7 +143,7 @@ static int __init init_gfs2_fs(void)
 
 	gfs2_register_debugfs();
 
-	printk("GFS2 (built %s %s) installed\n", __DATE__, __TIME__);
+	printk("GFS2 installed\n");
 
 	return 0;
 

Dne 5.4.2011 16:59, Michal Marek napsal(a):

Quoted 10 lines

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Steven Whitehouse <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 fs/gfs2/main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Hi,

I don't see this patch in today's linux-next. Any objection against me applying it to the kbuild-2.6.git repository?

Thanks,
Michal

Quoted 3 lines

I don't see this patch in today's linux-next. Any objection against me applying it to the kbuild-2.6.git repository?

No, I think that should be ok. It was added as a method to spot when someone had compiled their own module against a distro kernel, but tbh this isn't a problem in practice, so I don't think it will be a problem,

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc "David S. Miller" <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 net/atm/lec.c |    2 +-
 net/atm/mpc.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

net/atm/lec.c +1 -1

index 38754fd..cb14ddf 100644
@@ -1173,7 +1173,7 @@ static int __init lane_module_init(void)
 #endif
 
 	register_atm_ioctl(&lane_ioctl_ops);
-	pr_info("lec.c: " __DATE__ " " __TIME__ " initialized\n");
+	pr_info("lec.c: initialized\n");
 	return 0;
 }
 

net/atm/mpc.c +1 -1

index 644cdf0..3ccca42 100644
@@ -1482,7 +1482,7 @@ static __init int atm_mpoa_init(void)
 	if (mpc_proc_init() != 0)
 		pr_info("failed to initialize /proc/mpoa\n");
 
-	pr_info("mpc.c: " __DATE__ " " __TIME__ " initialized\n");
+	pr_info("mpc.c: initialized\n");
 
 	return 0;
 }

Dne 5.4.2011 16:59, Michal Marek napsal(a):

Quoted 11 lines

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc "David S. Miller" <[email protected]>

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 net/atm/lec.c |    2 +-
 net/atm/mpc.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Hi,

I don't see this patch in today's linux-next. Any objection against me applying it to the kbuild-2.6.git repository?

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Jon Maloy <[email protected]>

Cc Allan Stephens <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 net/tipc/core.c |    3 +--

 1 files changed, 1 insertions(+), 2 deletions(-)

net/tipc/core.c +1 -3

index e071579..33532fe 100644
@@ -185,8 +185,7 @@ static int __init tipc_init(void)
        if (tipc_log_resize(CONFIG_TIPC_LOG) != 0)
                warn("Unable to create log buffer\n");
 
-       info("Activated (version " TIPC_MOD_VER
-            " compiled " __DATE__ " " __TIME__ ")\n");
+       info("Activated (version " TIPC_MOD_VER ")\n");
 
        tipc_own_addr = 0;
        tipc_remote_management = 1;
--

1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time. As the buildDate field is part of the userspace API, I replaced it with the date of the last code change.

Cc Greg Kroah-Hartman <[email protected]>

Signed-off-by Michal Marek <[email protected]>

---
 drivers/char/rio/rioinit.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

The kernel already prints its build timestamp during boot, no need to repeat it in random drivers and produce different object files each time.

Cc Doug Thompson <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Michal Marek <[email protected]>

---
 drivers/edac/amd76x_edac.c  |    2 +-
 drivers/edac/amd8111_edac.c |    2 +-
 drivers/edac/amd8131_edac.c |    2 +-
 drivers/edac/cpc925_edac.c  |    2 +-
 drivers/edac/e752x_edac.c   |    2 +-
 drivers/edac/e7xxx_edac.c   |    2 +-
 drivers/edac/edac_module.c  |    2 +-
 drivers/edac/i5000_edac.c   |    2 +-
 drivers/edac/i5400_edac.c   |    2 +-
 drivers/edac/i7300_edac.c   |    2 +-
 drivers/edac/i7core_edac.c  |    2 +-

 drivers/edac/i82860_edac.c  |    2 +-
 drivers/edac/i82875p_edac.c |    2 +-
 drivers/edac/i82975x_edac.c |    2 +-
 drivers/edac/mpc85xx_edac.h |    2 +-
 drivers/edac/mv64x60_edac.h |    2 +-
 drivers/edac/ppc4xx_edac.c  |    2 +-
 drivers/edac/r82600_edac.c  |    2 +-
 18 files changed, 18 insertions(+), 18 deletions(-)