From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 0/3] introduce new evdev interface type Date: Tue, 01 Dec 2015 11:47:52 +0100 Message-ID: <6792470.H7eb3IQorJ@wuerfel> References: <1448618432-32357-1-git-send-email-pingbo.wen@linaro.org> <3322044.DFSNLmiFGl@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Pingbo Wen Cc: y2038-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, Dmitry Torokhov , aksgarg1989-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-api@vger.kernel.org On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote: > Hi, Arnd >=20 > >>>>=20 > >>>> The patch series add three evdev interface type: > >>>>=20 > >>>> - EV_IF_LEGACY > >>>> send event by input_event. This is the default option, keep kern= el > >>>> backward compatible. > >>>=20 > >>> The problem I see with this approach is that it still breaks any > >>> legacy source code that is compiled with a new libc that uses 64-= bit > >>> time_t. If we are requiring source code changes for building user= s > >>> of input devices with a new libc, we can easily get them to handl= e > >>> the overflow (they normally only care about the microsecond porti= on > >>> anyway, so it doesn't matter in most cases), or to use monotonic = time. > >>=20 > >> I don=E2=80=99t think so. > >>=20 > >> Actually, from the view of userspace, EV_IF_LEGACY interface is wo= rk > >> exactly the same as old evdev. We didn=E2=80=99t change anything i= n input_event > >> and input_event_compat. And the problem you said will still be the= re, > >> even without those patches. > >=20 > > I think we're still talking past one another. I thought we had esta= blished > > that > >=20 > > 1. the current interface is broken when time_t changes in user spac= e >=20 > What kinds of changes in time_t? Extending it to 64-bits in both kern= el > and userspace? Ok, I get confused here, if there are some sample code= s > or use-cases here, it will help me a lot. We don't change time_t in the kernel, we just try to replace it with time64_t, or ktime_t where appropriate. What I meant is the problem when glibc defines their time_t to be 'long long' so that user space can be built that runs after 2038. This changes the timeval and timespec definitions, so a process that tries to use 'struct input_event' has a different layout compared to what the kernel has. I though that we had already discussed that multiple times. > > 2. we can fix it by redefining struct input_event in a way that > > is independent of time_t > > 3. once both user space and kernel are using the same ABI independe= nt > > of time_t, we can look improving the timestamps so they don't > > overflow > > 4. the monotonic timestamp interface already avoids the overflow, s= o > > it would be sufficient as a solution for 3. > >=20 > > Where did I lose you here? Did you find any other facts that I > > was missing? I don't know whether the two new event structures make > > the interface better in some other way, but it seems mostly unrelat= ed > > to either of the two problems we already have with time_t (the > > ABI mismatch, and the use of non-monotonic timestamps). >=20 > It seems we are mismatch here. >=20 > Actually input_composite_event has the similar structure with input_e= vent, > but with a nicer definition, which can take both monotonic and non-mo= notonic > timestamps safely. >=20 > What I assumed here, is that leaving EV_IF_LEGACY as a untouched, dep= recated > interface. If userspace try to adapt to new libc and kernel, it shoul= d move > to new interface. The userspace can do a lazy update, keep the code u= ntouched, > but suffer the y2038 problem by itself. =46orcing the move to the new API is very ugly, because you can't do it in a way that works on old kernels as well, unless you then try to supp= ort both APIs at runtime. Just requiring user space to switch to monotonic time is easily done, as it can likely work either way. > We can force kernel using monotonic time in EV_IF_LEGACY interface, a= nd > making input_event independent from time_t(after evdev has converted = to > input_value, it=E2=80=99s easy to do that), but that also imply users= pace > must change their code to fit this change. If changing userspace code= is > a mandatory option, why not to force them do a complete conversion? Most user space programs won't care, as they don't even look at the tv_= sec portion, and the goal is to avoid having to change them. There is still an open question to how exactly we want to get user spac= e to change. We could do some compile-time trick by having a union in struct input_e= vent and mark the existing timeval part as deprecated, so we flag any use of= the 32-bit tv_sec member, such as: struct input_event { #if !defined(__KERNEL__) && __TIME_T_BITS =3D=3D __BITS_PER_LONG struct timeval time; #else struct { union { __u32 tv_sec __attribute__((deprecated)); __u32 tv_sec_monotonic; }; __s32 tv_usec; } time; #endif __u16 type; __u16 code; __s32 value; }; Another option is to do a runtime change, and always set the time field to zero when the kernel is built without support for 32-bit time_t and user space has not yet called the ioctl to change to monotonic time= =2E We can also do a combination of the two. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755941AbbLAKr7 (ORCPT ); Tue, 1 Dec 2015 05:47:59 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:49744 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754967AbbLAKr4 convert rfc822-to-8bit (ORCPT ); Tue, 1 Dec 2015 05:47:56 -0500 From: Arnd Bergmann To: Pingbo Wen Cc: y2038@lists.linaro.org, Dmitry Torokhov , aksgarg1989@gmail.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH 0/3] introduce new evdev interface type Date: Tue, 01 Dec 2015 11:47:52 +0100 Message-ID: <6792470.H7eb3IQorJ@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1448618432-32357-1-git-send-email-pingbo.wen@linaro.org> <3322044.DFSNLmiFGl@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" X-Provags-ID: V03:K0:g8frT4ZvN+3aktZDZWM7S91Q49QcLgaUdP1Tgf5rUX9TyHEpPT9 IMtz3hXTf3hY+jU6+NiLj6RWssNES6w8XGpyj3tK8+krShLALsbxCULvQAiOuoLkniZoV67 iKlmJFWxQKyEjoYJe2Y8q2Gvd71QHhydmaoZvyXpaHFHKSFW7uMWpJ291a7E0vZ+RPJm/x1 2N9BeKKcjrGpjA4CmO85A== X-UI-Out-Filterresults: notjunk:1;V01:K0:NYwwm00RSQ8=:ouKEynb6gDlW+7RcqwNqBP Mu5wLt7VAO30zTUi4MYE+Xft1PO5I4J04aGhufkvE2I5E72fp/Vim+FWD5Aw8rI3J4SQ24XmA DCvPf0kHbmhSPgZPfoO9E24qw2/SU/vfDAeg3djCohbu9eQPpeoZmz8BCk7IpdTMxAWSYnkCJ PDFJyg5383Kv/L8P9zmU393WtB7zMytj3whIRQLXbX1TgZTeove5mG64cwOVfQWhMqm184Eub jugT/wd7Wrh/WgZVWIPzOGHyuZ2w92ngoGb5K7ItgQBF7/UVUqOdvYOSHYFNqsnB5TktkYLbf XHtB4MPVRUpWOgmSoi/uR1ze3HebIbDyEdo0T4q05c3gWSTuWdgC1ORmlxfaLRcBWIxcoJ5Zx 9sADKxJgwGwTgBg1cIspV1iwvgvKaxHxoPHTuyfeMbaAvWpJT9O6S2pg+DochJ8D3dSQalwy8 BujAic1CxZ3fp18LrTd+cG+h9y1zUeVJBbkuHQOFhtN3PfmSTk8pVSiRF4l+Y7ggQvslrZ3mJ pv7Q3wAkid3jxlSre+/cc1IbqF9/PxIih9hnSGRxlvTaqnHMhdnDOJYC2ZiVaCCossfp39OH/ omSBSPujHZYZYyLNLunjHjVCYzWMaQ18XqOgoI23UihfiYaDMl2u3an8O7ckTRMIO6ehQcRto PFUA0n15Xdame1H9neg5x8skB/6xK4EtTt1rSighj88on/KVJwYJxHr1r/HwwjqSpEe96LPsj y+6bhm/N8vNryGRc Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote: > Hi, Arnd > > >>>> > >>>> The patch series add three evdev interface type: > >>>> > >>>> - EV_IF_LEGACY > >>>> send event by input_event. This is the default option, keep kernel > >>>> backward compatible. > >>> > >>> The problem I see with this approach is that it still breaks any > >>> legacy source code that is compiled with a new libc that uses 64-bit > >>> time_t. If we are requiring source code changes for building users > >>> of input devices with a new libc, we can easily get them to handle > >>> the overflow (they normally only care about the microsecond portion > >>> anyway, so it doesn't matter in most cases), or to use monotonic time. > >> > >> I don’t think so. > >> > >> Actually, from the view of userspace, EV_IF_LEGACY interface is work > >> exactly the same as old evdev. We didn’t change anything in input_event > >> and input_event_compat. And the problem you said will still be there, > >> even without those patches. > > > > I think we're still talking past one another. I thought we had established > > that > > > > 1. the current interface is broken when time_t changes in user space > > What kinds of changes in time_t? Extending it to 64-bits in both kernel > and userspace? Ok, I get confused here, if there are some sample codes > or use-cases here, it will help me a lot. We don't change time_t in the kernel, we just try to replace it with time64_t, or ktime_t where appropriate. What I meant is the problem when glibc defines their time_t to be 'long long' so that user space can be built that runs after 2038. This changes the timeval and timespec definitions, so a process that tries to use 'struct input_event' has a different layout compared to what the kernel has. I though that we had already discussed that multiple times. > > 2. we can fix it by redefining struct input_event in a way that > > is independent of time_t > > 3. once both user space and kernel are using the same ABI independent > > of time_t, we can look improving the timestamps so they don't > > overflow > > 4. the monotonic timestamp interface already avoids the overflow, so > > it would be sufficient as a solution for 3. > > > > Where did I lose you here? Did you find any other facts that I > > was missing? I don't know whether the two new event structures make > > the interface better in some other way, but it seems mostly unrelated > > to either of the two problems we already have with time_t (the > > ABI mismatch, and the use of non-monotonic timestamps). > > It seems we are mismatch here. > > Actually input_composite_event has the similar structure with input_event, > but with a nicer definition, which can take both monotonic and non-monotonic > timestamps safely. > > What I assumed here, is that leaving EV_IF_LEGACY as a untouched, deprecated > interface. If userspace try to adapt to new libc and kernel, it should move > to new interface. The userspace can do a lazy update, keep the code untouched, > but suffer the y2038 problem by itself. Forcing the move to the new API is very ugly, because you can't do it in a way that works on old kernels as well, unless you then try to support both APIs at runtime. Just requiring user space to switch to monotonic time is easily done, as it can likely work either way. > We can force kernel using monotonic time in EV_IF_LEGACY interface, and > making input_event independent from time_t(after evdev has converted to > input_value, it’s easy to do that), but that also imply userspace > must change their code to fit this change. If changing userspace code is > a mandatory option, why not to force them do a complete conversion? Most user space programs won't care, as they don't even look at the tv_sec portion, and the goal is to avoid having to change them. There is still an open question to how exactly we want to get user space to change. We could do some compile-time trick by having a union in struct input_event and mark the existing timeval part as deprecated, so we flag any use of the 32-bit tv_sec member, such as: struct input_event { #if !defined(__KERNEL__) && __TIME_T_BITS == __BITS_PER_LONG struct timeval time; #else struct { union { __u32 tv_sec __attribute__((deprecated)); __u32 tv_sec_monotonic; }; __s32 tv_usec; } time; #endif __u16 type; __u16 code; __s32 value; }; Another option is to do a runtime change, and always set the time field to zero when the kernel is built without support for 32-bit time_t and user space has not yet called the ioctl to change to monotonic time. We can also do a combination of the two. Arnd