summaryrefslogtreecommitdiff
path: root/fs/btrfs/extent_io.c
diff options
context:
space:
mode:
authorDmitry Torokhov <dmitry.torokhov@gmail.com>2010-12-14 23:53:21 -0800
committerDmitry Torokhov <dmitry.torokhov@gmail.com>2010-12-14 23:55:21 -0800
commitab4e0192196b8d4e43a3945742d4996da934a86f (patch)
tree7aeeec6e5fe84dcb1b3026c7cc6c0f81807f0922 /fs/btrfs/extent_io.c
parent57a7872fa0f03e90be0fa224b9ea533f5b03ee4f (diff)
Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2
The desire to keep old names for the EVIOCGKEYCODE/EVIOCSKEYCODE while extending them to support large scancodes was a mistake. While we tried to keep ABI intact (and we succeeded in doing that, programs compiled on older kernels will work on newer ones) there is still a problem with recompiling existing software with newer kernel headers. New kernel headers will supply updated ioctl numbers and kernel will expect that userspace will use struct input_keymap_entry to set and retrieve keymap data. But since the names of ioctls are still the same userspace will happily compile even if not adjusted to make use of the new structure and will start miraculously fail in the field. To avoid this issue let's revert EVIOCGKEYCODE/EVIOCSKEYCODE definitions and add EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2 so that userspace can explicitly select the style of ioctls it wants to employ. Reviewed-by: Henrik Rydberg <rydberg@euromail.se> Acked-by: Jarod Wilson <jarod@redhat.com> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Diffstat (limited to 'fs/btrfs/extent_io.c')
0 files changed, 0 insertions, 0 deletions