From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760807AbcJ1Moq (ORCPT ); Fri, 28 Oct 2016 08:44:46 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:64482 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760530AbcJ1Mon (ORCPT ); Fri, 28 Oct 2016 08:44:43 -0400 From: Arnd Bergmann To: Peter Hutterer Cc: Deepa Dinamani , Dmitry Torokhov , linux-input@vger.kernel.org, Linux Kernel Mailing List , y2038 Mailman List Subject: Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106 Date: Fri, 28 Oct 2016 14:44:31 +0200 Message-ID: <2186645.hbFdEOdHp0@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20161028044642.GA28017@jelly> References: <1476761253-13450-1-git-send-email-deepa.kernel@gmail.com> <20161028044642.GA28017@jelly> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:b2m3hJlbrc6Ay9XCG1SDlfgxyvDp0UylheOgCS5KjAJtDgKOIaf 1UW7cMDe1SbLVTKCAq4+0BxLXAjmnITGVuZPczijGOdL+wPjeyukR6y8+A3JE5uc7kQlzS6 diZxE49SR3bo6mB0G2BYRmMJO8ycuaFQoZfbLgHj1/ZvYXUYoDDI/fdTIlimo2RvVXCt1Oz aWay7s+gvkRVU/Z4vv1nw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Wpul2T3tZSo=:jk6pr01hx7DQxYRTiFxTjU UCJkwEJDh0ZbluC4iQtE2kRejJE46qVD1VKViCxlKqWN1B62ll9LqEkXe77i/nda6prSc1jyM rGHia3nMlLhqenfHqx1aopkt6GY5r6YaWh8DB0AE3Mfa06EgoNAw5hVDQX1DCnByXhcw6tlV4 S+XhroQ/nG5qWWPeoIwijCqGxMg34EMPwsm6oW06T/B2dlls9zT9HLZzqyoYp+e5Mx2wpr1jP j6EiLkyK5uMnlkdVChij+sx+I6p7BVX0enRr+RBUr/4agjH8QioPaPZn+G7+r2gvKFOBekYl9 19Srbh6TGfLve7ebPFRmRzvIjhi84ombKxUcWxWF6wcEc8aEFLUILrIR20MzFUAZnjoPpXDrg IrAYgq+5jHDG80rfL2W6flTQza35vUfvLSbt1QROLp5TFgPAuh5s9QKPum0KyOWu1hYFjAqFY 6z+BcWCwF6VcoEq4fzST3KA11qWljchWJqttO8VYkS6hc0nAtbQrPMaeL+/zOM92d56ZSbqMi S8n0Wz2KtH6wgJMEthl9tEGaRrAMUwy8sUle53RRSJ/ElFYFYabUAVRR/LbwSkNObTXNm5zoU 3mpWbMP7KwqmD9IYXXIiOtkTyICIXlz4pajL1Iuf0QeTlSqff+U7t5BrteC4QwOAbeWKtmjGY sPwTpIIKO2TSG77xscJ7PnF+WwrfmwzHGQdvAlQmF8eaQeX2gtneOlb5lZtbUm5vLLhmx0Zhj 5fUUMVYAri3J41CJ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, October 28, 2016 2:46:42 PM CEST Peter Hutterer wrote: > On Thu, Oct 27, 2016 at 03:24:55PM -0700, Deepa Dinamani wrote: > > On Wed, Oct 26, 2016 at 7:56 PM, Peter Hutterer > > wrote: > > > On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote: > > > general comment here - please don't name it "raw_input_event". > > > First, when you grep for input_event you want the new ones to show up too, > > > so a struct input_event_raw would be better here. That also has better > > > namespacing in general. Second though: the event isn't any more "raw" than > > > the previous we had. > > > > > > I can't think of anything better than struct input_event_v2 though. > > > > The general idea was to leave the original struct input_event as a > > common interface for userspace (as it cannot be deleted). > > So reading raw data unformatted by the userspace will have the new > > struct raw_input_event format. > > This was the reason for the "raw" in the name. > > > > struct input_event_v2 is fine too, if this is more preferred. I think input_event_v2 would be more confusing. An alternative to raw_input_event might be __kernel_input_event, which parallels things like __kernel_off_t that is also independent from the user space off_t in the same way that the user space input_event structure will get redefined in a way that is incompatible with the kernel ABI. > > >> 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. > > > > > > Doesn't this break *all* of userspace then? I don't see anything to > > > negotiate the type of input event the kernel gives me. And nothing right now > > > checks for EVDEV_VERSION, so they all just assume it's a struct > > > input_event. Best case, if the available events aren't a multiple of > > > sizeof(struct input_event) userspace will bomb out, but unless that happens, > > > everyone will just happily read old-style events. > > > > > > So we need some negotiation what is acceptable. Which also needs to address > > > the race conditions we're going to get when events start coming in before > > > the client has announced that it supports the new-style events. > > > > No, this does not break any userspace right now. > > Both struct input_event and struct raw_input_event are exactly the same today. > > oh, right, the ABI is the same. I see that now, thanks. One minor difference is that the seconds in raw_input_event are 'unsigned', so even with the 'real' time domain, we can represent times from 1970 to 2106, whereas 'timeval' represents times between 1902 and 2038. Once user space has a 64-bit time_t and the conversion function in libinput that Deepa suggested, the raw_input_event is only used on the kernel ABI and the normal timestamps will work fine. > > And, hence any library that results in a call to libevdev_set_fd() > > will fail if it is not this updated driver. > > without having seen the libevdev patch - that sounds like a bad idea . there > are plenty of usecases where libevdev_set_fd() is called but timestamps in > events just don't matter. So we may need need some more negotiation between > the library user, libevdev and the kernel. I also don't see any strict dependency at all: the binary data format has not changed, and I agree we absolutely should not break running a newly built library on old kernels. We can also safely assume that any user space that is actually built for 64-bit time_t is also running on a recent enough kernel, as today's kernels do not support 64-bit time_t yet. Arnd