Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S942913AbcJ0XNA (ORCPT ); Thu, 27 Oct 2016 19:13:00 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:33942 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933978AbcJ0XM6 (ORCPT ); Thu, 27 Oct 2016 19:12:58 -0400 Date: Thu, 27 Oct 2016 16:12:54 -0700 From: Dmitry Torokhov To: Deepa Dinamani Cc: linux-input@vger.kernel.org, Linux Kernel Mailing List , Arnd Bergmann , y2038 Mailman List , Peter Hutterer , Benjamin Tissoires , Jiri Kosina , Hans de Goede Subject: Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106 Message-ID: <20161027231254.GA12312@dtor-ws> References: <1476761253-13450-1-git-send-email-deepa.kernel@gmail.com> <1476761253-13450-4-git-send-email-deepa.kernel@gmail.com> <20161027022420.GC31660@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2557 Lines: 60 On Thu, Oct 27, 2016 at 03:25:43PM -0700, Deepa Dinamani wrote: > >> struct timeval is not y2038 safe. > >> All usage of timeval in the kernel will be replaced by > >> y2038 safe structures. > >> > >> 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. > >> > >> Leave the original input_event as is. This is to maintain > >> backward compatibility with existing userspace interfaces > >> that use input_event. > >> Introduce a new replacement struct raw_input_event. > >> This replaces timeval with struct input_timeval. This structure > >> maintains time in __kernel_ulong_t or compat_ulong_t to allow > >> for architectures to override types as in the case of x32. > >> > >> The change requires any userspace utilities reading or writing > >> from event nodes to update their reading format to match > >> raw_input_event. The changes to the popular libraries will be > >> posted along with the kernel changes. > >> The driver version is also updated to reflect the change in > >> event format. > > > > If users are forced to update to adapt to the new event format, should > > we consider more radical changes? For example, does it make sense to > > send timestamp on every event? Maybe we should only send it once per > > event packet (between EV_SYN/SYN_REPORT)? What granularity do we need? > > Is there anything else in current protocol that we'd like to change? > > I did see the thread with Pingbo's patches where you had a similar comment. > > I see my series as decoupling the kernel input event format from the > userspace format. > The formats also are really the same still. > Could this be considered the first step towards changing the protocol? I really do not see the point. I think we agree that the current protocol is not working past 2038 and it does not seem we can fix it transparently for the user. So we need to define new protocol and let kernel and clients negotiate which one is used. I am not concerned about in-kernel representation much as it does not get stored anywhere so we can adjust it as needed without too much effort. > > The protocol changes might need new interfaces to be defined between libraries. > And, could end up being a substantial change. > Would a step by step approach make sense? It would depend largely on the scope. Thanks. -- Dmitry