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
On Thu, Oct 22, 2015 at 1:31 PM, Arnd Bergmann arnd@arndb.de wrote:
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.
Not an issue!
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
Thanks for answering all the questions. Things are way clearer now.
-
Amitoj Kaur Chawla -
Arnd Bergmann