From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>,
Mark Lord <kernel@teksavvy.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
linux-input@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Date: Wed, 26 Jan 2011 06:09:45 +1000 [thread overview]
Message-ID: <AANLkTi=1Mh0JrYk5itvef7O7e7pR+YKos-w56W5q4B8B@mail.gmail.com> (raw)
In-Reply-To: <20110125164803.GA19701@core.coreip.homeip.net>
On Wed, Jan 26, 2011 at 2:48 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> We should be able to handle the case where scancode is valid even though
> it might be unmapped yet. This is regardless of what version of
> EVIOCGKEYCODE we use, 1 or 2, and whether it is sparse keymap or not.
>
> Is it possible to validate the scancode by driver?
More appropriately, why not just revert the thing? The version change
and the buggy EINVAL return both.
As Mark said, breaking user space simply isn't acceptable. And since
breaking user space isn't acceptable, then incrementing the version is
stupid too.
The way we add new ioctl's is not by incrementing some "ABI version"
crap. It's by adding new ioctl's or system calls or whatever that
simply used to return -ENOSYS or other error before, while preserving
the old ABI. That way old binaries don't break (for _ANY_ reason), and
new binaries can see "oh, this doesn't support the new thing".
Linus
next prev parent reply other threads:[~2011-01-25 20:10 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-23 17:03 2.6.36/2.6.37: broken compatibility with userspace input-utils ? Mark Lord
2011-01-24 17:54 ` Dmitry Torokhov
2011-01-25 0:32 ` Mark Lord
2011-01-25 0:55 ` Dmitry Torokhov
2011-01-25 4:13 ` Mark Lord
2011-01-25 4:20 ` Dmitry Torokhov
2011-01-25 4:37 ` Mark Lord
2011-01-25 4:43 ` Mark Lord
2011-01-25 4:55 ` Dmitry Torokhov
2011-01-25 5:04 ` Mark Lord
2011-01-25 5:07 ` Mark Lord
2011-01-25 5:15 ` Mark Lord
2011-01-25 5:31 ` Dmitry Torokhov
2011-01-25 6:52 ` Dmitry Torokhov
2011-01-25 14:42 ` Extending rc-core/userspace to handle bigger scancodes - Was: " Mauro Carvalho Chehab
2011-01-25 16:55 ` Dmitry Torokhov
2011-01-26 9:44 ` Mauro Carvalho Chehab
2011-01-25 11:42 ` Mauro Carvalho Chehab
2011-01-25 14:32 ` Mark Lord
2011-01-25 16:48 ` Dmitry Torokhov
2011-01-25 20:09 ` Linus Torvalds [this message]
2011-01-25 20:54 ` Dmitry Torokhov
2011-01-25 21:01 ` Dmitry Torokhov
2011-01-25 21:20 ` Linus Torvalds
2011-01-25 21:20 ` Linus Torvalds
2011-01-25 21:50 ` Dmitry Torokhov
2011-01-25 22:00 ` Mauro Carvalho Chehab
2011-01-25 22:22 ` Mark Lord
2011-01-25 23:29 ` Dmitry Torokhov
2011-01-26 2:00 ` Dmitry Torokhov
2011-01-26 11:26 ` Mauro Carvalho Chehab
2011-01-26 13:08 ` Gerd Hoffmann
2011-01-26 14:18 ` Mauro Carvalho Chehab
2011-01-26 14:52 ` Gerd Hoffmann
2011-01-26 16:46 ` Dmitry Torokhov
2011-01-26 16:51 ` Dmitry Torokhov
2011-01-26 17:29 ` Mauro Carvalho Chehab
2011-01-26 18:24 ` Dmitry Torokhov
2011-01-26 19:16 ` Gerd Hoffmann
2011-01-26 19:28 ` Mark Lord
2011-01-26 20:09 ` Gerd Hoffmann
2011-01-26 19:28 ` Mauro Carvalho Chehab
2011-01-26 19:32 ` Dmitry Torokhov
2011-01-26 20:07 ` Gerd Hoffmann
2011-01-26 19:27 ` Mark Lord
2011-01-26 14:58 ` Mark Lord
2011-01-26 17:41 ` Mauro Carvalho Chehab
2011-01-26 17:59 ` Dmitry Torokhov
2011-01-26 19:30 ` Mark Lord
2011-01-26 15:05 ` Mark Lord
2011-01-26 16:44 ` Dmitry Torokhov
2011-01-26 19:31 ` Mark Lord
2011-01-26 19:38 ` Dmitry Torokhov
2011-01-26 17:32 ` Mauro Carvalho Chehab
2011-01-26 19:33 ` Mark Lord
2011-01-26 19:41 ` Dmitry Torokhov
2011-01-26 19:47 ` Mark Lord
2011-01-26 19:50 ` Dmitry Torokhov
2011-01-26 21:41 ` Mark Lord
2011-01-26 21:49 ` Mark Lord
2011-01-26 22:07 ` Dmitry Torokhov
2011-01-26 22:04 ` Dmitry Torokhov
2011-01-27 1:01 ` Mark Lord
2011-01-27 1:07 ` Mark Lord
2011-01-27 2:12 ` Dmitry Torokhov
2011-01-27 3:18 ` Mark Lord
2011-01-27 6:38 ` Dmitry Torokhov
2011-01-27 10:30 ` Mauro Carvalho Chehab
2011-01-27 15:00 ` Mark Lord
2011-01-27 17:21 ` Dmitry Torokhov
2011-01-27 18:58 ` Mauro Carvalho Chehab
2011-01-28 9:39 ` Dmitry Torokhov
2011-01-28 11:55 ` Mauro Carvalho Chehab
2011-01-28 16:40 ` Dmitry Torokhov
2011-01-28 17:01 ` Mauro Carvalho Chehab
2011-01-28 17:33 ` Dmitry Torokhov
2011-01-28 18:15 ` Mauro Carvalho Chehab
2011-01-28 18:34 ` Dmitry Torokhov
2011-01-28 20:53 ` Mark Lord
2011-01-27 14:54 ` Mark Lord
2011-01-27 16:39 ` Dmitry Torokhov
2011-01-27 18:12 ` Mark Lord
2011-01-27 19:53 ` Dmitry Torokhov
2011-01-28 16:42 ` Dmitry Torokhov
2011-01-28 20:55 ` Mark Lord
2011-01-28 21:03 ` Mark Lord
2011-01-28 21:09 ` Dmitry Torokhov
2011-01-25 22:25 ` Linus Torvalds
2011-01-25 5:29 ` Dmitry Torokhov
2011-01-25 14:28 ` Mark Lord
2011-02-02 14:31 ` Chase Douglas
2011-02-02 16:58 ` Dmitry Torokhov
2011-02-02 20:00 ` Chase Douglas
2011-02-02 21:54 ` Mark Lord
2011-02-02 22:04 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTi=1Mh0JrYk5itvef7O7e7pR+YKos-w56W5q4B8B@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=dmitry.torokhov@gmail.com \
--cc=kernel@teksavvy.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.