From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754831AbbK3PNT (ORCPT ); Mon, 30 Nov 2015 10:13:19 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:63405 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754332AbbK3PNQ convert rfc822-to-8bit (ORCPT ); Mon, 30 Nov 2015 10:13:16 -0500 From: Arnd Bergmann To: Pingbo Wen Cc: y2038@lists.linaro.org, dmitry.torokhov@gmail.com, 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: Mon, 30 Nov 2015 16:13:11 +0100 Message-ID: <3322044.DFSNLmiFGl@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> <8705201.iaeQDTRocP@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" X-Provags-ID: V03:K0:7v7D+rndpzYS/Y+7/bvFQS2YB57DrhICxVQ8aTZ4iiO0WXnM464 Q2XraLTfCihyhCmWvfImmjtObNx3lulKDXlscZKhA5yecMSO6pRL9c/BZHDdzyHTSZL9hlf OZaaDnqLwlkI+tpKpUJx0OkhYKO+8dWvgv+f+V31vdnkSHR2jsc1MyrivOt9exqjlBNIHZA vG30htTJFS4l9Ztxdv0xQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:+w1Oj/igsiw=:EfHwKns9JnQuU82IroNKAe VkpO74sLdkT2ej0ZcnUG7nA/n7lToKQ3MOC6AicrYyA72BQ8/HO9bxGEJOTIo+K5IVUI1H0Id DYEdnCvMtsoZMMXh6wtfbV4C16Peazn8vnsuS8Jxv4zPD5YCbBzvwgaSAGxMtFAYXkWlcVCpi G/q3+B7iCV9TWtPt+xZnDyUhakUVtoDUmoXZrNZZTippxmOezs/ySSiO9EqEG71BA9AFI7MKc Vri9iEPmG/z8nA8zJRtqWyKXIT5P4vfPgUutpp3np2X0VvHkKI4xdK/HhdmYoC6FoJhOAJf+w kDDeGFeMs2IWesXh8wzwg0eVlnxt2t7bIDVAMHucds+X61U0H4RTNxwQ0XFv+bvvqArDewQuB EbetK6iQBfIgHXYpwv9G0JTOsCG7UPunn3AhIJddyrSr7ko8U2peAYd2E8S6vZB/C+Gj9KEBh NBoTAAKraYvEd1W4KdXryPvtpT1Ctas23lgyH/8BcC/2CcioqovVv7qY0z5CuRZA0fj/owe8T TNEAaTPgj5kEeuegMGqUpzVv5/oVVrAwE9OF59Q0q1D4BhDO/U8HXR+wISBBPzZAEWXpvgi1Q 2AV+e4baTuZcicV3lLMO1MNfOnItEOTVOEllUS1GEX6rMcD0SzM6ZxNbkgwVxYZDqhSqto2MZ 7zD9JheMmkZxtGR/x8cAotvh6RFCp9q9yTpX0cFKcEynUfsS5spoA4oXmTWtR6I3z77t2werS /WUq12InGV0uYvy/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday 29 November 2015 17:13:50 Pingbo Wen wrote: > > 在 2015年11月28日，00:58，Arnd Bergmann 写道： > > > > On Friday 27 November 2015 18:00:29 WEN Pingbo wrote: > >> To solve the y2038 problem in input_event, I had some attempts before [1], > >> and this is the second one. > >> > >> We can force userspace to use monotonic time in event timestamp, so the > >> 'struct timeval' is enough to keep y2038-safe, as Arnd suggested. But we > >> can not find a way to make kernel compatible with old binaries, which use > >> realtime, and there are still some devices, which depend on realtime. > >> > >> So I get a idea to add a new evdev interface, which is y2038 safe. And > >> userspace can switch between the old and new interface via ioctl. > >> > >> 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 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). Arnd