| Message ID | 1302015561-21047-13-git-send-email-mmarek@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 2011-04-05 at 17:10 +0200, Armin Schindler wrote: > On Tue, 5 Apr 2011, Michal Marek wrote: > > 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 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. Ben.
On Tue, 5 Apr 2011, Ben Hutchings wrote: > On Tue, 2011-04-05 at 17:10 +0200, Armin Schindler wrote: >> On Tue, 5 Apr 2011, Michal Marek wrote: >>> 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 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'. Armin -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 05 Apr 2011 17:10:34 +0200, Armin Schindler said: > On Tue, 5 Apr 2011, Michal Marek wrote: > > 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'.
On Tue, Apr 05, 2011 at 06:07:05PM +0200, Armin Schindler wrote: > On Tue, 5 Apr 2011, Ben Hutchings wrote: >> On Tue, 2011-04-05 at 17:10 +0200, Armin Schindler wrote: >>> On Tue, 5 Apr 2011, Michal Marek wrote: >>>> 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 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'. If we needs this somehow a generic solution is required. Ad hoc solutions in some modules is not the way to go. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 5.4.2011 21:17, Valdis.Kletnieks@vt.edu wrote: > On Tue, 05 Apr 2011 17:10:34 +0200, Armin Schindler said: >> On Tue, 5 Apr 2011, Michal Marek wrote: >>> 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'. Exactly. Build timestamps are only a poor substitute for proper version tracking. If you want to be able to reproduce the build of a binary, you want it to embed some source revision, not the date when you built it. For the kernel, you can use KBUILD_BUILD_TIMESTAMP=<source timestamp>, for out-of-tree modules, you need to come up with something own. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dne 5.4.2011 17:10, Armin Schindler napsal(a): > On Tue, 5 Apr 2011, Michal Marek wrote: >> 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? thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 25 May 2011, Michal Marek wrote: > Dne 5.4.2011 17:10, Armin Schindler napsal(a): >> On Tue, 5 Apr 2011, Michal Marek wrote: >>> 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. > I don't think so. So is there an > objection against applying this patch? No objection. Please go ahead with the patch. Thanks Armin -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 26.5.2011 10:15, Armin Schindler wrote: > On Wed, 25 May 2011, Michal Marek wrote: >> Dne 5.4.2011 17:10, Armin Schindler napsal(a): >>> On Tue, 5 Apr 2011, Michal Marek wrote: >>>> 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. > >> I don't think so. So is there an >> objection against applying this patch? > > No objection. Please go ahead with the patch. OK, thanks. Applied to kbuild-2.6.git#trivial. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/isdn/hardware/eicon/divasfunc.c b/drivers/isdn/hardware/eicon/divasfunc.c index d36a4c0..0bbee78 100644 --- a/drivers/isdn/hardware/eicon/divasfunc.c +++ b/drivers/isdn/hardware/eicon/divasfunc.c @@ -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)) } /*
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 <mac@melware.de> Cc: netdev@vger.kernel.org Signed-off-by: Michal Marek <mmarek@suse.cz> --- drivers/isdn/hardware/eicon/divasfunc.c | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-)