On Monday 29 June 2015 22:23:27 Bamvor Zhang Jian wrote:

diff --git a/include/uapi/linux/ppdev.h b/include/uapi/linux/ppdev.h index dc18c5d..d62a47d 100644 --- a/include/uapi/linux/ppdev.h +++ b/include/uapi/linux/ppdev.h @@ -74,8 +74,18 @@ struct ppdev_frob_struct { #define PPSETPHASE _IOW(PP_IOCTL, 0x94, int) /* Set and get port timeout (struct timeval's) */ -#define PPGETTIME _IOR(PP_IOCTL, 0x95, struct timeval) -#define PPSETTIME _IOW(PP_IOCTL, 0x96, struct timeval) +/* Force application use 64 time_t ioctl */ +/* TODO: It is an open question about we should use a __xxx_timeval or an

• • implicit array.
• • replace struct __kernel_timeval with __s32[4]
• • replace struct compat_timeval with __s32[2]
• */

+#define PPGETTIME PPGETTIME64 +#define PPSETTIME PPSETTIME64 +#define PPGETTIME64 _IOR(PP_IOCTL, 0x95, struct __kernel_timeval) +#define PPSETTIME64 _IOW(PP_IOCTL, 0x96, struct __kernel_timeval) +#define PPGETTIME32 _IOR(PP_IOCTL, 0x9c, struct __kernel_compat_timeval) +#define PPSETTIME32 _IOW(PP_IOCTL, 0x9d, struct __kernel_compat_timeval)

As commented before, these definitions should probably not be part of the user-visible header file.

The main reason for using an __s64[2] array instead of struct __kernel_timeval is to avoid adding __kernel_timeval: 'timeval' is thoroughly deprecated and we don't want to establish new interfaces with that.

In case of this driver, nobody would ever want to change their user space to use a 64-bit __kernel_timeval instead of timeval and explicitly call PPGETTIME64 instead of PPGETTIME, because we are only dealing with an interval here, and a 32-bit second value is sufficient to represent that. Instead, the purpose of your patch is to make the kernel cope with user space that happens to use a 64-bit time_t based definition of 'struct timeval' and passes that to the ioctl.

Arnd

[re-sent with fixed y2038 list]