From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752424AbbIPH4l (ORCPT ); Wed, 16 Sep 2015 03:56:41 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:57706 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751179AbbIPH4j (ORCPT ); Wed, 16 Sep 2015 03:56:39 -0400 From: Arnd Bergmann To: Hans Verkuil Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, y2038@lists.linaro.org, Mauro Carvalho Chehab , linux-api@vger.kernel.org, linux-samsung-soc@vger.kernel.org Subject: Re: [PATCH 6/7] [RFC] [media]: v4l2: introduce v4l2_timeval Date: Wed, 16 Sep 2015 09:56:21 +0200 Message-ID: <7758607.pJFdek7ljg@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <55F91162.8030002@xs4all.nl> References: <1442332148-488079-1-git-send-email-arnd@arndb.de> <2432018.5rA5LXfiBo@wuerfel> <55F91162.8030002@xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:gzoPjAPHjvnsWtAqTvULnJ1ZH3t+pbXYPwvoa7JLnPB8trnVzLQ Z8/R2uYpl8d7LByRL/LhxaKk2Q9cQEQon12ZZtY7DeIO7q97MSp71ZhblN+AZwuYv5p9A30 aOzRZJHmuqBHtKbGPl8LDM/Z3MjVX7jwY1293VxzIfsnk421dP1yldkVfOfLWUfjo9LDAaK sebg7HJQwcOsywT/cDIlg== X-UI-Out-Filterresults: notjunk:1;V01:K0:9VlGcgrEDOQ=:X5R4ZOSKXglfArxgNFRBlD Pdn74k73JF7RS6yNGYgDZj3SAPg9knM0CMGrF/WsaJ6Nwo1yrXNZfokrjtPugIa/g3h+d/pgq s5eYZklt6W8J9MnE3dCksGKHkbEn1/CDBYBqCDmOTrLEU9y1smT2o0wIJYWtpGkhxlnhLklrV RDGH9rX9svxvq4UHMvCyWT6PB7lskZ+pq2BKUaN9kDXF6DuqxL8EKvpof6gCGSMioe5e2IvKk gpYF00an0tH9MvC33cWWOxq+3GfE/s37XSFnwAiKQjxSsfns6W40/gMnLnHbv/IGhTBg7X1bh +kxfUVVA7Iy73WFojWOZwwXqksuJtJlf8xD9uKBD1Wxfw9xGM21P5ULMOvfETNBpENK5UqMi6 Dfb9oAzks9VsE+0A2MOhL0v9U6SXqT7rclv7NUdo60s/SQF5irWijervSjm4ygY4v/CW0OfJ/ 2f5Xt8vFLSbXggbhReQ9KXJ9gOVPmKSn7anX/46HQFNcECnKP0eWxwwkDtBPSl8Y3YHTh/38w H7qjir1Hk75EpbUggKhusEThdhV8yf4xMjmfvHkRm76vYeqZx9YYtHsD/oUCAzCzXWi98iztV ifnwfgv39Jc3K1UYzreGOXOVSo/bNWUYE94ZXRcoO1J94FTv6BPogV/nw3f/rfA1VZkr6rlqo 9NYgIkH9KxwuL4Yp6v1+AwCpvtkVjZRZn1yYXXjTUAip/mzRGYnRfOjhHwd4mJ46VgIYYN9yx pGUvizKoGzc0tsyp Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 16 September 2015 08:51:14 Hans Verkuil wrote: > > a) Similar to my first attempt, define a new struct v4l2_timeval, but > > only use it when building with a y2038-aware libc, so we don't break > > existing environments: > > > > /* some compile-time conditional that we first need to agree on with libc */ > > #if __BITS_PER_TIME_T > __BITS_PER_LONG > > struct v4l2_timeval { long tv_sec; long tv_usec; } > > #else > > #define v4l2_timeval timeval > > #endif > > > > This means that any user space that currently assumes the timestamp > > member to be a 'struct timeval' has to be changed to access the members > > individually, or get a build error. > > The __BITS_PER_TIME_T trick has to be used in a couple of other subsystems > > too, as some of them have no other way to identify an interface > > I don't like this as this means some applications will compile on 64 bit or > with a non-y2038-aware libc, but fail on a 32-bit with y2038-aware libc. This > will be confusing and it may take a long time before the application developer > discovers this. Right. > > b) Keep the header file unchanged, but deal with both formats of v4l2_buffer > > in the kernel. Fortunately, all ioctls that pass a v4l2_buffer have > > properly defined command codes, and it does not get passed using a > > read/write style interface. This means we move the v4l2_buffer32 > > handling from v4l2-compat-ioctl32.c to v4l2-ioctl.c and add an in-kernel > > v4l2_buffer64 that matches the 64-bit variant of v4l2_buffer. > > This way, user space can use either definition of time_t, and the > > kernel will just handle them natively. > > This is going to be the most common way to handle y2038 compatibility > > in device drivers, and it has the additional advantage of simplifying > > the compat path. > > This would work. Ok. So the only downside I can think of for this is that it uses a slightly less efficient format with additional padding in it. The kernel side will be a little ugly as I'm trying to avoid defining a generic timeval64 structure (the generic syscalls should not need one), but I'll try to implement it first to see how it ends up. > > c) As you describe above, introduce a new v4l2_buffer replacement with > > a different layout that does not reference timeval. For this case, I > > would recommend using a single 64-bit nanosecond timestamp that can > > be generated using ktime_get_ns(). > > However, to avoid ambiguity with the user space definition of struct > > timeval, we still have to hide the existing 'struct v4l2_buffer' from > > y2038-aware user space by enclosing it in '#if __BITS_PER_TIME_T > > > __BITS_PER_LONG' or similar. > > Right, and if we do that we still have the problem I describe under a). So we > would need to implement b) regardless. > > In other words, choosing c) doesn't depend on y2038 and it should be decided > on its own merits. > > I've proposed this as a topic to the media workshop we'll have during the Linux > Kernel Summit. Thanks, good idea. I'll be at the kernel summit, but don't plan to attend the media workshop otherwise. If you let me know about the schedule, I can come to this session (or ping me on IRC or hangout when it starts). Arnd