Hi, Arnd >>>> >>>> The patch series add three evdev interface type: >>>> >>>> - EV_IF_LEGACY >>>> send event by input_event. This is the default option, keep kernel >>>> backward compatible. >>> >>> The problem I see with this approach is that it still breaks any >>> legacy source code that is compiled with a new libc that uses 64-bit >>> time_t. If we are requiring source code changes for building users >>> of input devices with a new libc, we can easily get them to handle >>> the overflow (they normally only care about the microsecond portion >>> anyway, so it doesn't matter in most cases), or to use monotonic time. >> >> I don’t think so. >> >> Actually, from the view of userspace, EV_IF_LEGACY interface is work >> exactly the same as old evdev. We didn’t change anything in input_event >> and input_event_compat. And the problem you said will still be there, >> even without those patches. > > I think we're still talking past one another. I thought we had established > that > > 1. the current interface is broken when time_t changes in user space What kinds of changes in time_t? Extending it to 64-bits in both kernel and userspace? Ok, I get confused here, if there are some sample codes or use-cases here, it will help me a lot. > 2. we can fix it by redefining struct input_event in a way that > is independent of time_t > 3. once both user space and kernel are using the same ABI independent > of time_t, we can look improving the timestamps so they don't > overflow > 4. the monotonic timestamp interface already avoids the overflow, so > it would be sufficient as a solution for 3. > > Where did I lose you here? Did you find any other facts that I > was missing? I don't know whether the two new event structures make > the interface better in some other way, but it seems mostly unrelated > to either of the two problems we already have with time_t (the > ABI mismatch, and the use of non-monotonic timestamps). It seems we are mismatch here. Actually input_composite_event has the similar structure with input_event, but with a nicer definition, which can take both monotonic and non-monotonic timestamps safely. What I assumed here, is that leaving EV_IF_LEGACY as a untouched, deprecated interface. If userspace try to adapt to new libc and kernel, it should move to new interface. The userspace can do a lazy update, keep the code untouched, but suffer the y2038 problem by itself. We can force kernel using monotonic time in EV_IF_LEGACY interface, and making input_event independent from time_t(after evdev has converted to input_value, it’s easy to do that), but that also imply userspace must change their code to fit this change. If changing userspace code is a mandatory option, why not to force them do a complete conversion? Pingbo-- 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
