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(-)
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))
}
/*
--
1.7.4.1
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.
Armin
> 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(-)
>
> 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))
> }
>
> /*
> --
> 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/
>
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.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
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
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
On 5.4.2011 21:17, [email protected] 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
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
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
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