From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106 Date: Thu, 27 Oct 2016 16:12:54 -0700 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="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: y2038-bounces@lists.linaro.org Sender: "Y2038" To: Deepa Dinamani Cc: Jiri Kosina , Arnd Bergmann , Hans de Goede , y2038 Mailman List , Linux Kernel Mailing List , Peter Hutterer , Benjamin Tissoires , linux-input@vger.kernel.org List-Id: linux-input@vger.kernel.org T24gVGh1LCBPY3QgMjcsIDIwMTYgYXQgMDM6MjU6NDNQTSAtMDcwMCwgRGVlcGEgRGluYW1hbmkg d3JvdGU6Cj4gPj4gc3RydWN0IHRpbWV2YWwgaXMgbm90IHkyMDM4IHNhZmUuCj4gPj4gQWxsIHVz YWdlIG9mIHRpbWV2YWwgaW4gdGhlIGtlcm5lbCB3aWxsIGJlIHJlcGxhY2VkIGJ5Cj4gPj4geTIw Mzggc2FmZSBzdHJ1Y3R1cmVzLgo+ID4+Cj4gPj4gc3RydWN0IGlucHV0X2V2ZW50IG1haW50YWlu cyB0aW1lIGZvciBlYWNoIGlucHV0IGV2ZW50Lgo+ID4+IFJlYWwgdGltZSB0aW1lc3RhbXBzIGFy ZSBub3QgaWRlYWwgZm9yIGlucHV0IGFzIHRoaXMKPiA+PiB0aW1lIGNhbiBnbyBiYWNrd2FyZHMg YXMgbm90ZWQgaW4gdGhlIHBhdGNoIGE4MGI4M2I3YjgKPiA+PiBieSBKb2huIFN0dWx0ei4gSGVu Y2UsIGhhdmluZyB0aGUgaW5wdXRfZXZlbnQudGltZSBmaWVsZHMKPiA+PiBvbmx5IGJpZyBlbm91 Z2ggZm9yIG1vbm90b25pYyBhbmQgYm9vdCB0aW1lcyBhcmUKPiA+PiBzdWZmaWNpZW50Lgo+ID4+ Cj4gPj4gTGVhdmUgdGhlIG9yaWdpbmFsIGlucHV0X2V2ZW50IGFzIGlzLiBUaGlzIGlzIHRvIG1h aW50YWluCj4gPj4gYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0aW5nIHVzZXJzcGFj ZSBpbnRlcmZhY2VzCj4gPj4gdGhhdCB1c2UgaW5wdXRfZXZlbnQuCj4gPj4gSW50cm9kdWNlIGEg bmV3IHJlcGxhY2VtZW50IHN0cnVjdCByYXdfaW5wdXRfZXZlbnQuCj4gPj4gVGhpcyByZXBsYWNl cyB0aW1ldmFsIHdpdGggc3RydWN0IGlucHV0X3RpbWV2YWwuIFRoaXMgc3RydWN0dXJlCj4gPj4g bWFpbnRhaW5zIHRpbWUgaW4gX19rZXJuZWxfdWxvbmdfdCBvciBjb21wYXRfdWxvbmdfdCB0byBh bGxvdwo+ID4+IGZvciBhcmNoaXRlY3R1cmVzIHRvIG92ZXJyaWRlIHR5cGVzIGFzIGluIHRoZSBj YXNlIG9mIHgzMi4KPiA+Pgo+ID4+IFRoZSBjaGFuZ2UgcmVxdWlyZXMgYW55IHVzZXJzcGFjZSB1 dGlsaXRpZXMgcmVhZGluZyBvciB3cml0aW5nCj4gPj4gZnJvbSBldmVudCBub2RlcyB0byB1cGRh dGUgdGhlaXIgcmVhZGluZyBmb3JtYXQgdG8gbWF0Y2gKPiA+PiByYXdfaW5wdXRfZXZlbnQuIFRo ZSBjaGFuZ2VzIHRvIHRoZSBwb3B1bGFyIGxpYnJhcmllcyB3aWxsIGJlCj4gPj4gcG9zdGVkIGFs b25nIHdpdGggdGhlIGtlcm5lbCBjaGFuZ2VzLgo+ID4+IFRoZSBkcml2ZXIgdmVyc2lvbiBpcyBh bHNvIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUgY2hhbmdlIGluCj4gPj4gZXZlbnQgZm9ybWF0Lgo+ ID4KPiA+IElmIHVzZXJzIGFyZSBmb3JjZWQgdG8gdXBkYXRlIHRvIGFkYXB0IHRvIHRoZSBuZXcg ZXZlbnQgZm9ybWF0LCBzaG91bGQKPiA+IHdlIGNvbnNpZGVyIG1vcmUgcmFkaWNhbCBjaGFuZ2Vz PyBGb3IgZXhhbXBsZSwgZG9lcyBpdCBtYWtlIHNlbnNlIHRvCj4gPiBzZW5kIHRpbWVzdGFtcCBv biBldmVyeSBldmVudD8gTWF5YmUgd2Ugc2hvdWxkIG9ubHkgc2VuZCBpdCBvbmNlIHBlcgo+ID4g ZXZlbnQgcGFja2V0IChiZXR3ZWVuIEVWX1NZTi9TWU5fUkVQT1JUKT8gV2hhdCBncmFudWxhcml0 eSBkbyB3ZSBuZWVkPwo+ID4gSXMgdGhlcmUgYW55dGhpbmcgZWxzZSBpbiBjdXJyZW50IHByb3Rv Y29sIHRoYXQgd2UnZCBsaWtlIHRvIGNoYW5nZT8KPiAKPiBJIGRpZCBzZWUgdGhlIHRocmVhZCB3 aXRoIFBpbmdibydzIHBhdGNoZXMgd2hlcmUgeW91IGhhZCBhIHNpbWlsYXIgY29tbWVudC4KPiAK PiBJIHNlZSBteSBzZXJpZXMgYXMgZGVjb3VwbGluZyB0aGUga2VybmVsIGlucHV0IGV2ZW50IGZv cm1hdCBmcm9tIHRoZQo+IHVzZXJzcGFjZSBmb3JtYXQuCj4gVGhlIGZvcm1hdHMgYWxzbyBhcmUg cmVhbGx5IHRoZSBzYW1lIHN0aWxsLgo+IENvdWxkIHRoaXMgYmUgY29uc2lkZXJlZCB0aGUgZmly c3Qgc3RlcCB0b3dhcmRzIGNoYW5naW5nIHRoZSBwcm90b2NvbD8KCkkgcmVhbGx5IGRvIG5vdCBz ZWUgdGhlIHBvaW50LiBJIHRoaW5rIHdlIGFncmVlIHRoYXQgdGhlIGN1cnJlbnQKcHJvdG9jb2wg aXMgbm90IHdvcmtpbmcgcGFzdCAyMDM4IGFuZCBpdCBkb2VzIG5vdCBzZWVtIHdlIGNhbiBmaXgg aXQKdHJhbnNwYXJlbnRseSBmb3IgdGhlIHVzZXIuIFNvIHdlIG5lZWQgdG8gZGVmaW5lIG5ldyBw cm90b2NvbCBhbmQgbGV0Cmtlcm5lbCBhbmQgY2xpZW50cyBuZWdvdGlhdGUgd2hpY2ggb25lIGlz IHVzZWQuCgpJIGFtIG5vdCBjb25jZXJuZWQgYWJvdXQgaW4ta2VybmVsIHJlcHJlc2VudGF0aW9u IG11Y2ggYXMgaXQgZG9lcyBub3QKZ2V0IHN0b3JlZCBhbnl3aGVyZSBzbyB3ZSBjYW4gYWRqdXN0 IGl0IGFzIG5lZWRlZCB3aXRob3V0IHRvbyBtdWNoCmVmZm9ydC4KCj4gCj4gVGhlIHByb3RvY29s IGNoYW5nZXMgbWlnaHQgbmVlZCBuZXcgaW50ZXJmYWNlcyB0byBiZSBkZWZpbmVkIGJldHdlZW4g bGlicmFyaWVzLgo+IEFuZCwgY291bGQgZW5kIHVwIGJlaW5nIGEgc3Vic3RhbnRpYWwgY2hhbmdl Lgo+IFdvdWxkIGEgc3RlcCBieSBzdGVwIGFwcHJvYWNoIG1ha2Ugc2Vuc2U/CgpJdCB3b3VsZCBk ZXBlbmQgbGFyZ2VseSBvbiB0aGUgc2NvcGUuCgpUaGFua3MuCgotLSAKRG1pdHJ5Cl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClkyMDM4IG1haWxpbmcgbGlz dApZMjAzOEBsaXN0cy5saW5hcm8ub3JnCmh0dHBzOi8vbGlzdHMubGluYXJvLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3kyMDM4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 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 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