Re: [PATCH 6/7] [RFC] [media]: v4l2: introduce v4l2_timeval

[Hans Verkuil]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/