On Wednesday 18 November 2015 19:25:48 Amitoj Kaur Chawla wrote:
On Tue, Nov 17, 2015 at 2:20 AM, Arnd Bergmann arnd@arndb.de wrote:
On Thursday 12 November 2015 18:54:51 Amitoj Kaur Chawla wrote:
32 bit systems using 'struct timeval' will break in the year 2038, so we modify the code appropriately.
This patch replaces the use of struct timeval and do_gettimeofday() with ktime_get_real_seconds() which returns a 64 bit value which is safer than struct timeval.
The patch looks good now, but the description doesn't completely capture the line of thinking yet:
This patch replaces u32 time storing variable with u64 variable to store the 64 bit seconds value returned by ktime_get_real_seconds().
Since we can't change the layout of the structure retrieving profile data as it is being used in a vendor specific command that can get sent from user space, a cast to time_t has been added to the assignment statement.
The connection between "we can't change this" and "adding a cast to time_t" here is what makes this rather confusing. The cast really has no effect here until we get to the point when the time_t definition is removed and it triggers a build error, or if someone goes looking for drivers that still use time_t in order to clean them up.
Arnd
So something along the lines:
This patch replaces u32 time storing variable with u64 variable to store the 64 bit seconds value returned by ktime_get_real_seconds().
A cast to time_t has also been added to the assignment statement which will cause a build error when we eventually remove the time_t definition from the kernel.
We can't change the layout of the structure retrieving profile data as it is being used in a vendor specific command that can get sent from user space.
Ok, sounds good.
Arnd