On 09/16/2015 09:56 AM, Arnd Bergmann wrote: > 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). Are you also attending the ELCE in Dublin? We could have a quick talk there. I think the discussion whether to switch to a new v4l2_buffer struct isn't really dependent on anything y2038. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html