From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933016AbbLCM4i (ORCPT ); Thu, 3 Dec 2015 07:56:38 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:57529 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178AbbLCM4g (ORCPT ); Thu, 3 Dec 2015 07:56:36 -0500 From: Arnd Bergmann To: y2038@lists.linaro.org Cc: Pingbo Wen , linux-api@vger.kernel.org, Dmitry Torokhov , linux-kernel@vger.kernel.org, aksgarg1989@gmail.com, linux-input@vger.kernel.org Subject: Re: [Y2038] [PATCH 0/3] introduce new evdev interface type Date: Thu, 03 Dec 2015 13:56:32 +0100 Message-ID: <2642116.RNDaIWhxZX@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <3471947.HA9TBa0js5@wuerfel> References: <1448618432-32357-1-git-send-email-pingbo.wen@linaro.org> <1BB6B3AD-F547-49F8-886A-56EF80CE62FE@linaro.org> <3471947.HA9TBa0js5@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:Ltd5jdq5e9Wo4C5jLBp0xU6JCNZrg4spfks49kW4u+/6nMH1KIH 9/1L8ueuU/r4z31X8F8kHIsHPfGZ2hsCBjJ+9dwKJSJMY/i20cTlNTsH9NfNvbmJ0/fer4C zAOL2C038qo1939cKjwRezroBRHrlqh9ypGFt/AzwTxpUWpB1GMt8woPYas9U94HCS5W6LW eBfgMfAAXRYdzxcOqhIQQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:WWuiSIIE7HI=:AA4aUkPygU1HbMOyTCxgcC Kac/+v/QmVp/8okqyFD4OfkhwtfXQNfA2HoomdibCamWVVfCEaTEvQdHQIP3MWD9fKBqI0ZpK IRtD8OsIps8KUhcUBqNMZVLAAEmdA+ac1bVCv7O41r+qptRfg+qkaj1+pshHpajOrE1ZslAwq qp9LgFzNny622gQF96vWyzIw/ROX15QEpSCcYbJ/R+jNivTlVbSOwuVFC2owI/Qla940fo+9h PovvONdxle1M5ghKy94nUdayLX9p7Wl5KU8OVm7iQwR9G4lHvFpHjrFm4T+41nbkFKxWcIntu +PDC9jOpE9CIimVQ+VHTjwpCCLyqScGoAHcPDi2G4dfkOoWTQ8U/R57IBtZy+7R2RgcLhYqwU PWJQgXGNx/N8DIBOJvtqD0vAsS6fRKex8VwdbZKivhxKxnSrmVVRvelL5uxJlLkycjqTajjGG YiljG0cYJKo0vt7PYlRDKp+YOdMk6Xd6MxQnw1BOe2/EmYxJxHE2s4tuerquB7+20DDJ0EpeJ d7RBWG7bHpTjRWnkgxW1OTwqkNfuKqIECvENCS16n9OUggsf49QslrCAEqfaQj1wOZ+IDHyGy CeqJFbSmYsAwc5Q7RWefCUDMKs0e73oPVW3kEQ5i8z7egpEHeSUFFG5VFj0zLolKZKa6FqqYb SPxAP4Ge6qHH9UGa0lFf/CsgjlqV/VG9JDtCwjFBcQnHLrKoeD3zMca4zPgntuKIryS2fbRxx NUOy6Txh6cTi/O2t Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 03 December 2015 13:54:47 Arnd Bergmann wrote: > > > 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; > > > }; > > > > I have one question here, if userspace use this structure, all helper functions > > of timeval will not work. And userspace need to write extra helper function for > > this fake timeval. This just create an another urgly time structure. > > Correct, this is a useful side-effect of the change: any user space access to > the event->time member that assumes it's a timeval will cause a compile-time > warning or error (depending on the access), which helps us identify the > broken code and fix it to use monotonic times as well as access the right > struct members. > To clarify, the code also intentionally only changes the types when we are compiling with a new 32-bit libc: everything that builds today will continue to build and work without warnings, unless it gets recompiled with 64-bit time_t and needs to be fixed. Arnd