From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752044AbbJFId1 (ORCPT ); Tue, 6 Oct 2015 04:33:27 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:50482 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962AbbJFIdX (ORCPT ); Tue, 6 Oct 2015 04:33:23 -0400 From: Arnd Bergmann To: Oliver Hartkopp Cc: netdev@vger.kernel.org, y2038@lists.linaro.org, linux-kernel@vger.kernel.org, "David S. Miller" , Marc Kleine-Budde , linux-can@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH 12/12] [RFC] can: avoid using timeval for uapi Date: Tue, 06 Oct 2015 10:32:58 +0200 Message-ID: <7548522.iLToS4O3HD@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5612C69C.7020803@hartkopp.net> References: <1443612402-3000775-1-git-send-email-arnd@arndb.de> <1443612402-3000775-13-git-send-email-arnd@arndb.de> <5612C69C.7020803@hartkopp.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:TIysvzrNgF9SL650d2PYAI8apBCeqQsixbTJ5bpECVcSCwwP+9X ujGZFsVN0Qj+FcWnnHInbdIzs257Udko3RanEE0q925uJUP8hm4p43KV9iJvaR9FaqXtAtR Xu7W4od2PeG4YaDSK29UfDCOUw9Qtl9HkgfHHH4obRODoBiAqVw8QeIRJ5zWTZ+BKH6KI+0 toWSDsBgqrEENXmNbnHzQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:8HwPiVesXbc=:GRdI0usYp6hic6ysDDk7Pw m3c4p04GmgD/CpDHJr26WG6Ic5pFZ0S3KFKxUHKKo8O0MthTmty/KODSY5ZhNM8/ocbvrB6Pl eTEu485lsvZsfhxnz2IciWBZ+txcy+zOO1dqInxlbcrsx24/dmuuwdLK2MF69wEyOZMTiY6V4 BOYQHtuldAO/o3kXnJSI3bH5Mg4/3lDLcxLonpqQWEg5vD5HJMlyZ0Fr+jk40+6VtArVWGJCv bWiPzEjMJ05OJIEZ+Fup5GrEtRg3c2Ad+7vFzPYVvpTcsZZXLc/pceFCqxlC973z8iD10LHc7 xXbJ4NArqJqHS1Roh+Qf/QuruHorkP4SFVvNKeA11FJVoXgYPIdNS/8VPmYiZ0vITNveTZEgg qquklguukAO5svCwEwmY+Q/htZdRHp0jwhqyZbhAGSx56SNhHhnqBQz1XnuBIeVvKXEAocdtf q4hitGDL6JA/oPa5JX2Jp+oAcTmts5/XtwS9SiurfHBDSKvrZdgi34myZz8jqVRF/ZFU3V5XE AZhZqeb1i4LyoPEkHeUbJpuMs+VXFMTXazwxUHprCTrBQPq/XiLxPY473ezZx9OvFJauCUPZD 8apQgxhxwGPZRGgDYZocRQRkf7QtbeBoOP/NL2jhD4Aq2v37CD/wGESOmB3fkFtId0t/kxeeM AhkwuA3B4KFK1tAjIVZaKahw/0G/KtGDzIZA70pcdQpm85RYeAHG/yPqOWV149Yb9HBCwuO6/ AOa26OqYxxPMivCQ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 05 October 2015 20:51:08 Oliver Hartkopp wrote: > > I double checked some (more) BCM applications I have access to. > > E.g. https://github.com/linux-can/can-tests > > When you do a 'git grep ival1' there you get something like > > tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 1; > tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0; > tst-bcm-cycle.c: msg.msg_head.ival1.tv_sec = 0; > tst-bcm-cycle.c: msg.msg_head.ival1.tv_usec = 0; > tst-bcm-dump.c: msg.msg_head.ival1.tv_sec = timeout / 1000000; > tst-bcm-dump.c: msg.msg_head.ival1.tv_usec = timeout % 1000000; > (..) > > So the usual way to assign values to ival1 and ival2 is NOT to assign an > existing struct timeval but to directly assign its tv_[u]sec elements. Ok, very good. > I applied your bcm.h changes to my local can-tests tree and it compiles > without any problems - as expected. I don't see any serious drawback with your > idea. I wonder whether developers would ever notice this change ... > > > We could address problem a) by using '__u32' or 'int' members > > rather than 'long', but that would have a more significant > > downside in also breaking support for all existing 64-bit user > > binaries that might be using this interface, which is likely > > not acceptable. > > Indeed. > > > Signed-off-by: Arnd Bergmann > > Cc: Oliver Hartkopp > > Thanks for your good suggestion to make the BCM API y2038 proof! > > Acked-by: Oliver Hartkopp Thanks. What is the normal path for CAN patches? Should I resend with your Ack and without the RFC for Marc to pick it up? Arnd