On Mon, Jan 08, 2018 at 04:07:22PM -0800, Deepa Dinamani wrote: > On Mon, Jan 8, 2018 at 1:51 PM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > Hi Deepa, > > > > On Sat, Jan 06, 2018 at 04:19:15PM -0800, Deepa Dinamani wrote: > >> struct timeval is not y2038 safe. > >> All usage of timeval in the kernel will be replaced by > >> y2038 safe structures. > >> The change is also necessary as glibc is introducing support > >> for 32 bit applications to use 64 bit time_t. Without this > >> change, many applications would incorrectly interpret values > >> in the struct input_event. > >> More details about glibc at > >> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign . > >> > >> struct input_event maintains time for each input event. > >> Real time timestamps are not ideal for input as this > >> time can go backwards as noted in the patch a80b83b7b8 > >> by John Stultz. Hence, having the input_event.time fields > >> only big enough for monotonic and boot times are > >> sufficient. > > > > I am happy with the patch, but have some concerns about changelog. The > > change does not really prevent anyone from using CLOCK_REALTIME past > > 2106, especially on 64 bit arches. We are simply extending range of > > reported seconds in input event by converting from signed to unsigned > > value. > > I was interpreting working incorrectly on 32 bit architectures, but > working correctly on 64 bit architectures as a failure of the feature > to use realtime clock at all. > But, you are correct that the patch does not actively do anything to > stop people from using realtime clock. > > >> > >> The change leaves the representation of struct input_event as is > >> on 64 bit architectures. But uses 2 unsigned long values on 32 bit > >> machines to support real timestamps until year 2106. > >> This intentionally breaks the ABI on 32 bit architectures and > >> compat handling on 64 bit architectures. > >> This is as per maintainer's preference to introduce compile time errors > >> rather than run into runtime incompatibilities. > > > > We are breaking API, not ABI though. The ABI for existing programs is > > exactly the same, it is only when system starts using the newer glibc > > supporting extended time the compilation will break. > > I was interpreting not being able to use negative timestamps on 32 bit > machines as breaking the ABI. > > >> The change requires any 32 bit userspace utilities reading or writing > >> from event nodes to update their reading format to match the new > >> input_event. The changes to the popular libraries will be posted once > >> we agree on the kernel change. > > I propose we have the following changelog: > > > > > > Input: extend usable life of event timestamps to 2106 on 32 bit systems > > > > The input events use struct timeval to store event time, unfortunately > > this structure is not y2038 safe and is being replaced in kernel with > > y2038 safe structures. > > > > Because of ABI concerns we can not change the size or the layout of > > structure input_event, so we opt to re-interpreting the 'seconds' part > > of timestamp as an unsigned value, effectively doubling the range of > > values, to year 2106. > > Newer glibc that has support for 32 bit applications to use 64 bit > > time_t supplies __USE_TIME_BITS64 define [1], that we can use to present > > the userspace with updated input_event layout. The updated layout will > > cause the compile time breakage, alerting applications and distributions > > maintainers to the issue. Existing 32 binaries will continue working > > without any changes until 2038. > > > > Ultimately userspace applications should switch to using monotonic or > > boot time clocks, as realtime clock is not very well suited for input > > event timestamps as it can go backwards (see a80b83b7b8 "Input: evdev - > > add CLOCK_BOOTTIME support" by by John Stultz). With monotonic clock the > > practical range of reported times will always fit into the pair of 32 > > bit values, as we do not expect any system to stay up for a hundred > > years without a single reboot. > > > > [1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign > > > > > > Please let me know if you disagee with the above. > > I'm fine with this commit text. Let me know if you would like me to update this. No, unless somebody yells I'll change it on my side. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
