[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2642116.RNDaIWhxZX@wuerfel>
Date: Thu, 03 Dec 2015 13:56:32 +0100
From: Arnd Bergmann <arnd@...db.de>
To: y2038@...ts.linaro.org
Cc: Pingbo Wen <pingbo.wen@...aro.org>, linux-api@...r.kernel.org,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-kernel@...r.kernel.org, aksgarg1989@...il.com,
linux-input@...r.kernel.org
Subject: Re: [Y2038] [PATCH 0/3] introduce new evdev interface type
On Thursday 03 December 2015 13:54:47 Arnd Bergmann wrote:
> > > 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.
>
> Correct, this is a useful side-effect of the change: any user space access to
> the event->time member that assumes it's a timeval will cause a compile-time
> warning or error (depending on the access), which helps us identify the
> broken code and fix it to use monotonic times as well as access the right
> struct members.
>
To clarify, the code also intentionally only changes the types when
we are compiling with a new 32-bit libc: everything that builds today
will continue to build and work without warnings, unless it gets
recompiled with 64-bit time_t and needs to be fixed.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists