Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-22 Thread Arnd Bergmann
On Sunday, June 19, 2016 5:26:59 PM CEST Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. > The macros are not y2038 safe. There is no plan to transition them into being > y2038 safe. > ktime_get_* api's can be used in their place. And,

Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-22 Thread Arnd Bergmann
On Sunday, June 19, 2016 5:26:59 PM CEST Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. > The macros are not y2038 safe. There is no plan to transition them into being > y2038 safe. > ktime_get_* api's can be used in their place. And,

Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-21 Thread Arnd Bergmann
On Monday, June 20, 2016 11:03:01 AM CEST you wrote: > On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani > wrote: > > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > > macros. > Gcc handles 8-byte structure returns (on most architectures) by >

Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-21 Thread Arnd Bergmann
On Monday, June 20, 2016 11:03:01 AM CEST you wrote: > On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani > wrote: > > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > > macros. > Gcc handles 8-byte structure returns (on most architectures) by > returning them as two

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-20 Thread Deepa Dinamani
> This version now looks ok to me. > > I do have a comment (or maybe just a RFD) for future work. > > It does strike me that once we actually change over the inode times to > use timespec64, the calling conventions are going to be fairly > horrendous on most 32-bit architectures. > > Gcc handles

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-20 Thread Deepa Dinamani
> This version now looks ok to me. > > I do have a comment (or maybe just a RFD) for future work. > > It does strike me that once we actually change over the inode times to > use timespec64, the calling conventions are going to be fairly > horrendous on most 32-bit architectures. > > Gcc handles

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-20 Thread Linus Torvalds
On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-20 Thread Linus Torvalds
On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we actually change over the inode

[PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-19 Thread Deepa Dinamani
The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros. The macros are not y2038 safe. There is no plan to transition them into being y2038 safe. ktime_get_* api's can be used in their place. And, these are y2038 safe. Thanks to Arnd Bergmann for all the guidance and

[PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

2016-06-19 Thread Deepa Dinamani
The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC macros. The macros are not y2038 safe. There is no plan to transition them into being y2038 safe. ktime_get_* api's can be used in their place. And, these are y2038 safe. Thanks to Arnd Bergmann for all the guidance and