On Wed, Oct 26, 2016 at 7:56 PM, Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > On Mon, Oct 17, 2016 at 08:27:32PM -0700, Deepa Dinamani wrote: >> struct timeval is not y2038 safe. >> All usage of timeval in the kernel will be replaced by >> y2038 safe structures. >> >> struct input_event maintains time for each input event. >> Real time timestamps are not ideal for input as this >> time can go backwards as noted in the patch a80b83b7b8 >> by John Stultz. Hence, having the input_event.time fields >> only big enough for monotonic and boot times are >> sufficient. >> >> Leave the original input_event as is. This is to maintain >> backward compatibility with existing userspace interfaces >> that use input_event. >> Introduce a new replacement struct raw_input_event. > > general comment here - please don't name it "raw_input_event". > First, when you grep for input_event you want the new ones to show up too, > so a struct input_event_raw would be better here. That also has better > namespacing in general. Second though: the event isn't any more "raw" than > the previous we had. > > I can't think of anything better than struct input_event_v2 though. The general idea was to leave the original struct input_event as a common interface for userspace (as it cannot be deleted). So reading raw data unformatted by the userspace will have the new struct raw_input_event format. This was the reason for the "raw" in the name. struct input_event_v2 is fine too, if this is more preferred. >> This replaces timeval with struct input_timeval. This structure >> maintains time in __kernel_ulong_t or compat_ulong_t to allow >> for architectures to override types as in the case of x32. >> >> The change requires any userspace utilities reading or writing >> from event nodes to update their reading format to match >> raw_input_event. The changes to the popular libraries will be >> posted along with the kernel changes. >> The driver version is also updated to reflect the change in >> event format. > > Doesn't this break *all* of userspace then? I don't see anything to > negotiate the type of input event the kernel gives me. And nothing right now > checks for EVDEV_VERSION, so they all just assume it's a struct > input_event. Best case, if the available events aren't a multiple of > sizeof(struct input_event) userspace will bomb out, but unless that happens, > everyone will just happily read old-style events. > > So we need some negotiation what is acceptable. Which also needs to address > the race conditions we're going to get when events start coming in before > the client has announced that it supports the new-style events. No, this does not break any userspace right now. Both struct input_event and struct raw_input_event are exactly the same today. This will be the case until a 2038-safe glibc is used with a 64 bit time_t flag. So these are the scenarios: 1. old kernel driver + new userspace -- should still be ok until 2038. Version checks could help discover these 2. new kernel driver + old userspace (without recompiled with new 2038 gblic) -- works because the format is really the same. The patch I posted to libevdev checks this driver version. And, hence any library that results in a call to libevdev_set_fd() will fail if it is not this updated driver. We could just do a similar check in every library also. I think the latter would be better. So, the kernel patches can go in as a no-op right now and then I can add version checks to respective user space libraries. -Deepa -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
