Re: [Y2038] [PATCH 0/3] fix y2038 problem in input_event

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 04 November 2015 11:35:20 Pingbo Wen wrote:
> > 在 2015年11月3日，09:43，Dmitry Torokhov <dmitry.torokhov@gmail.com> 写道：
> > 
> > On Mon, Nov 02, 2015 at 09:35:36PM +0800, WEN Pingbo wrote:
> >> Before this, I have discussed this problem with Arnd. And Arnd have
> >> an idea that by converting timeval to long / long in input_event, so that
> >> input_event structure size will be unchanged, and timeval structure will
> >> removed entirely. But we also need to avoid using CLOCK_REALTIME in
> >> userland, to keep the new input_event structure y2038 safe.
> >> 
> >> The input_event will only support monotonic time in Arnd's idea. And
> >> we still need to add wall time support for old 32-bit binary. 
> >> 
> >> Those patches try to keep original input capacity, and resolve y2038
> >> problem in input_event radically.
> >> 
> >> struct input_event is only used between kernel and userspace
> >> communication (except uinput). So that we can replace input_event
> >> with input_event64 in kernel entirely, and add a conversion in
> >> input_event_from/to_user() to keep compatible with old 32-bits binary.
> >> 
> >> userland can switch to input_event64, which is y2038 safe, via ioctl.
> > 
> > If we are forcing userspace to change the protocol I'd rather explore
> > whether we need to transmit the timestamp in each and every event. I
> > would much rather drop it and instead introduce new event code for
> > timestamp (we already have MSC_TIMESTAMP for hardware-generated
> > timestamps, maybe we can introduce new ones for kernel-generated
> > timestamps).
> 
> Yes, we can do that by replacing all input_event with input_value in kernel,
> and injecting a timestamp event after every normal event (maybe we can give
> userspace a option here).
> 
> But we still need do some conversion work in input_event_from/to_user to
> be compatible with old binary. And we need extend value field in
> ’struct input_value’ to s64, so the timestamp can be passed safely.

Right, that would be equivalent to Pingbo's approach (fixing the y2038
problem by requiring user space changes that are incompatible with
old kernels), but with a nicer interface.

The approach of leaving the event timestamps as 32 bit but requiring
montonic times in contrast would require only user space to change when
it cares about time stamps and doesn't already use montonic times.
Importantly, the modified user space would remain compatible with older
kernels as long as they support monotonic times. Those were introduced
by John Stultz in a80b83b7b8 ("Input: add infrastructure for selecting
clockid for event time stamps") and merged into linux-3.3, and are
generally a good idea because of time jumps.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html