> 在 2015年12月1日，18:47，Arnd Bergmann <arnd@xxxxxxxx> 写道：
>
> On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote:
>>
>>
>> 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.
>
> We don't change time_t in the kernel, we just try to replace it
> with time64_t, or ktime_t where appropriate.
>
> What I meant is the problem when glibc defines their time_t to
> be 'long long' so that user space can be built that runs after
> 2038. This changes the timeval and timespec definitions, so
> a process that tries to use 'struct input_event' has a different
> layout compared to what the kernel has.
Ok, I didn’t reach this point. Thanks to clarify.
>>
>> 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.
>
> Forcing the move to the new API is very ugly, because you can't do it
> in a way that works on old kernels as well, unless you then try to support
> both APIs at runtime.
>
> Just requiring user space to switch to monotonic time is easily done,
> as it can likely work either way.
It seems I’m more aggressive:) But the legacy binary can still live 30 years longer
without any changes.
>
>> 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?
>
> Most user space programs won't care, as they don't even look at the tv_sec
> portion, and the goal is to avoid having to change them.
>
> There is still an open question to how exactly we want to get user space
> to change.
>
> We could do some compile-time trick by having a union in struct input_event
> and mark the existing timeval part as deprecated, so we flag any use of the
> 32-bit tv_sec member, such as:
>
> struct input_event {
> #if !defined(__KERNEL__) && __TIME_T_BITS == __BITS_PER_LONG
> struct timeval time;
> #else
> struct {
> union {
> __u32 tv_sec __attribute__((deprecated));
> __u32 tv_sec_monotonic;
> };
> __s32 tv_usec;
> } time;
> #endif
> __u16 type;
> __u16 code;
> __s32 value;
> };
I have one question here, if userspace use this structure, all helper functions
of timeval will not work. And userspace need to write extra helper function for
this fake timeval. This just create an another urgly time structure.
And this method also forces most of old binaries to compile with new libc, adjust
their codes with new fake time structure.
Besides, I get an idea to combine your structure with input_composite_event:
union {
struct {
__s32 tv_usec;
__s32 tv_sec;
};
__s64 time;
} time;
I prefer to use a single s64 timestamp, if our goal is to remove timeval from kernel.
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
