Here is the third version for converting parport device(ppdev) to y2038 safe.
The first two version could found at [1],[2].
An y2038 safe application/kernel use 64bit time_t(aka time64_t) instead of 32bit
time_t. There are the 5 cases need to support:
summary |u:arch |u:tv_sec |k:arch |k:tv_sec
-------------------|-------|---------|-------|--------
32_y2038_unsafe |32 |32 |32 |32
32_y2038_safe |32 |64 |32 |64
compat_y2038_unsafe|32 |32 |64 |64
compat_y2038_safe |32 |64 |64 |64
64_y2038_safe |64 |64 |64 |64
notes:
1. xxx_y2038_safe/unsafe. 32 means app running on the 32bit kernel.
compat means 32bit app running on 64bit kernel. 64 means 64bit app
running on 64bit kernel.
2. 1.3.5 are the original one, we need keep the compatability. 2,4 is
new one we need to support.
There are different ways to do this. Convert to 64bit time and/or define
COMPAT_USE_64BIT_TIME 0 or 1 to indicate y2038 safe or unsafe.
But it is not mean that we need to convert all the time relative struct
to 64bit. Because some time relative struct(e.g. timeval in ppdev.c) is mainly
the offset of the real time.
The main issue in ppdev.c is PPSETTIME/PPGETTIME which transfer timeval between
user space and kernel. My approach here is handle them as different ioctl
command.
Build successful on arm64 and arm.
[1] https://lists.linaro.org/pipermail/y2038/2015-June/000522.html
[2] https://lists.linaro.org/pipermail/y2038/2015-June/000567.html
Bamvor Jian Zhang (2):
ppdev: convert to y2038 safe
ppdev: add support for compat ioctl
drivers/char/ppdev.c | 85 ++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 69 insertions(+), 16 deletions(-)
--
2.1.4
This is my second attempt to convert subsystem-wide code in v4l
for y2038 changes, removing uses of time_t in common files
and adding support for user space that defines time_t as 64 bit.
Based on the initial feedback from Hans Verkuil, I've changed the
ioctl handling to remain 100% compatible with existing headers,
which also makes it more likely that existing source code can
compile without changes.
This comes at a noticeable expense of adding complexity to
the v4l2-ioctl.c file, as we now have to handle two versions
of each ioctl command that passes a time_t in its arguments.
I have not added support for the new binary layout of v4l2_timeval
to v4l2-compat-ioctl32 yet, that is something I can do when the
basic approach has been agreed on.
Arnd
Arnd Bergmann (9):
[media] dvb: use ktime_t for internal timeout
[media] dvb: remove unused systime() function
[media] dvb: don't use 'time_t' in event ioctl
[media] exynos4-is: use monotonic timestamps as advertized
[media] make VIDIOC_DQEVENT work with 64-bit time_t
[media] use v4l2_get_timestamp where possible
[media] v4l2: introduce v4l2_timeval
[media] handle 64-bit time_t in v4l2_buffer
[media] omap3isp: support 64-bit version of omap3isp_stat_data
drivers/media/dvb-core/demux.h | 2 +-
drivers/media/dvb-core/dmxdev.c | 2 +-
drivers/media/dvb-core/dvb_demux.c | 17 +-
drivers/media/dvb-core/dvb_demux.h | 4 +-
drivers/media/dvb-core/dvb_net.c | 2 +-
drivers/media/dvb-frontends/dibx000_common.c | 10 -
drivers/media/dvb-frontends/dibx000_common.h | 2 -
drivers/media/pci/bt8xx/bttv-driver.c | 7 +-
drivers/media/pci/cx18/cx18-mailbox.c | 2 +-
drivers/media/pci/meye/meye.h | 2 +-
drivers/media/pci/zoran/zoran.h | 2 +-
drivers/media/platform/coda/coda.h | 2 +-
drivers/media/platform/exynos4-is/fimc-capture.c | 8 +-
drivers/media/platform/exynos4-is/fimc-lite.c | 7 +-
drivers/media/platform/omap/omap_vout.c | 4 +-
drivers/media/platform/omap3isp/isph3a_aewb.c | 2 +
drivers/media/platform/omap3isp/isph3a_af.c | 2 +
drivers/media/platform/omap3isp/isphist.c | 2 +
drivers/media/platform/omap3isp/ispstat.c | 20 +-
drivers/media/platform/omap3isp/ispstat.h | 4 +-
drivers/media/platform/s3c-camif/camif-capture.c | 8 +-
drivers/media/platform/vim2m.c | 2 +-
drivers/media/platform/vivid/vivid-ctrls.c | 2 +-
drivers/media/usb/cpia2/cpia2.h | 2 +-
drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
drivers/media/usb/gspca/gspca.c | 6 +-
drivers/media/usb/usbvision/usbvision.h | 2 +-
drivers/media/v4l2-core/v4l2-common.c | 6 +-
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 35 ----
drivers/media/v4l2-core/v4l2-dev.c | 1 +
drivers/media/v4l2-core/v4l2-event.c | 35 +++-
drivers/media/v4l2-core/v4l2-ioctl.c | 227 ++++++++++++++++++++---
drivers/media/v4l2-core/v4l2-subdev.c | 6 +
drivers/staging/media/omap4iss/iss_video.c | 5 +-
include/media/v4l2-common.h | 2 +-
include/media/v4l2-event.h | 2 +
include/media/videobuf-core.h | 2 +-
include/trace/events/v4l2.h | 12 +-
include/uapi/linux/dvb/video.h | 3 +-
include/uapi/linux/omap3isp.h | 19 ++
include/uapi/linux/videodev2.h | 78 ++++++++
41 files changed, 415 insertions(+), 145 deletions(-)
--
2.1.0.rc2
Before this, I have discussed this problem with Arnd. And Arnd have
an idea that by converting timeval to long / long in input_event, so that
input_event structure size will be unchanged, and timeval structure will
removed entirely. But we also need to avoid using CLOCK_REALTIME in
userland, to keep the new input_event structure y2038 safe.
The input_event will only support monotonic time in Arnd's idea. And
we still need to add wall time support for old 32-bit binary.
Those patches try to keep original input capacity, and resolve y2038
problem in input_event radically.
struct input_event is only used between kernel and userspace
communication (except uinput). So that we can replace input_event
with input_event64 in kernel entirely, and add a conversion in
input_event_from/to_user() to keep compatible with old 32-bits binary.
userland can switch to input_event64, which is y2038 safe, via ioctl.
WEN Pingbo (3):
evdev: convert input_event to input_event64
evdev: add new ioctl EVIOCSEVENT / EVIOCGEVENT
uinput: convert input_event to input_event64
drivers/input/evdev.c | 38 ++++++++++++-------
drivers/input/input-compat.c | 88 +++++++++++++++++++++++++++++++++++++-------
drivers/input/input-compat.h | 9 +++--
drivers/input/misc/uinput.c | 17 ++++++---
include/linux/uinput.h | 2 +-
include/uapi/linux/input.h | 18 +++++++++
6 files changed, 134 insertions(+), 38 deletions(-)
--
1.9.1
You have received a new fax.
Scanned fax document is attached to this email.
Scanned by: Daniel Chamberlain
Document name: scan_0000852481.doc
Date: Thu, 5 Nov 2015 03:19:32 +0300
Scan quality: 500 DPI
File size: 144 Kb
Pages sent: 3
Scanned in: 47 seconds
Thanks for using Interfax service!