This patch replaces timeval with timespec64 as 32 bit 'struct timeval'
will not give current time beyond 2038.
The patch changes the code to use ktime_get_real_ts64() which returns
a 'struct timespec64' instead of do_gettimeofday() which returns a
'struct timeval'
This patch also alters the format strings in sprintf() for now.tv_sec and
now.tv_nsec to incorporate 'long long' on 32 bit architectures and
leading zeroes respectively.
Signed-off-by: Amitoj Kaur Chawla <amitoj1606(a)gmail.com>
---
Changes in v2:
-change format string of now.tv_sec to '%llu'
-change format string of now.tv_nsec to '%.08lu'
drivers/misc/ibmasm/ibmasm.h | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/ibmasm/ibmasm.h b/drivers/misc/ibmasm/ibmasm.h
index 9b08344..d73be61 100644
--- a/drivers/misc/ibmasm/ibmasm.h
+++ b/drivers/misc/ibmasm/ibmasm.h
@@ -34,6 +34,7 @@
#include <linux/kref.h>
#include <linux/device.h>
#include <linux/input.h>
+#include <linux/time64.h>
/* Driver identification */
#define DRIVER_NAME "ibmasm"
@@ -53,9 +54,9 @@ extern int ibmasm_debug;
static inline char *get_timestamp(char *buf)
{
- struct timeval now;
- do_gettimeofday(&now);
- sprintf(buf, "%lu.%lu", now.tv_sec, now.tv_usec);
+ struct timespec64 now;
+ ktime_get_real_ts64(&now);
+ sprintf(buf, "%llu.%.08lu", (long long)now.tv_sec, now.tv_usec);
return buf;
}
--
1.9.1
Notice to Appear,
You have to appear in the Court on the October 27.
You are kindly asked to prepare and bring the documents relating to the case to Court on the specified date.
Note: If you do not come, the case will be heard in your absence.
The Court Notice is attached to this email.
Sincerely,
Frederick Kirkpatrick,
District Clerk.
On Thursday 22 October 2015 12:08:14 Amitoj Kaur Chawla wrote:
> Hi Arnd,
>
>
> A couple of doubts I had while working on some patches.
Hi Amitoj,
I've put the y2038 and outreachy mailing lists on Cc, I hope that's
ok with you.
You ask good and important questions, and it will help others to
read my reply as well.
> I was working on drivers/net/wireless/atmel.c which has time_t in it.
> According to the y2038 page it should be replaced with ktime_t. But
> while reading online on y2038, I found time64_t as well.
> My question, what is the difference between time64_t and ktime_t and
> how do you decide which to use where?
time64_t uses seconds, while ktime_t uses nanoseconds. They are both
appropriate solutions for the problem, but it depends on the driver's
requirements which one work better. Most drivers want sub-second
resolution, so ktime_t has to be used. When a driver is only interested
in seconds, using time64_t is more efficient, because it avoids the
64-bit integer division required to convert nanoseconds into seconds.
> I found another patch in an archive where you've mentioned
> ktime_get(), ktime_get_real(), ktime_get_ts64(),
> ktime_get_real_ts64(), ktime_get_seconds() and
> ktime_get_real_seconds().
> What is the difference between ktime_get() and ktime_get_ts64()?
ktime_get_ts64() returns a 'struct timespec64' rather than 'ktime_t'.
The two are essentially equivalent, but using ktime_t is generally
more preferred, except that converting ktime_t into timespec64 later
is again an expensive operation. If a driver wants separate
seconds/nanoseconds fields, using timespec64 is better.
> You've also mentioned there that 'real is used when driver wants to
> know wallclock but is okay with time going backwards.'
> I didn't understand this, how do you know that the driver is 'okay
> with time going backwards' ?
Most of them are not: if a driver wants to know how much time has
passed between two events, and it gets a negative answer, things
can go wrong.
An example for a driver that does not care about time going backwards
is one that just prints the current time in a printk() statement
and does not compare it to another time value.
There are also examples where you have to use 'real' time, in particular
when the time value is passed through an external interface with a
known format (e.g. to user processes, on the network, or stored on disk).
Here, changing the code to monotonic time causes problems for the code
on the other end of that interface.
Arnd
Hi,
I am following up on my previous email (mentioned below) to see if you had a
chance to review it.
Is there any more information you'd like to know from my end regarding the
email list?
Let me know your current target audience so that I can get back to you with
relevant information.
Let me know if we can schedule a quick call.
I appreciate a response from you.
Warm regards,
Emily
From: Emily Collins [mailto:emily.collins@edatalead.com]
Sent: Thursday, October 15, 2015 7:18 AM
To: 'y2038(a)lists.linaro.org'
Subject: Canonical end users
Hi,
Would you like to acquire list of Canonical end users?
Some of the technology contact database which you might be interested:
. Redhat
. Linux.
. Centos.
. Ubuntu and more.
Information fields: Contact First Name, Last Name, Job Title, Email Address,
Phone Number, Fax Number, Company Name, Company Physical Address, and
Company Web Address, SIC Code, NAICS code, Primary Industry, Employee Size,
Revenue, Technology Type
If you have any other requirement, let me know your criteria and I'll get
back to you with more relevant information.
Thank you and I look forward to hearing from you.
Regards
Emily Collins
Sr. Marketing Executive
________________________________________
We respect your privacy. If you do not wish to receive future e-mail please
reply with "REMOVE".